Platform Engineering vs DevOps at 50 Engineers: What to Build and What to Buy

Most build-vs-buy arguments about platform engineering are broken before they start, because people put a developer portal like Backstage on one side and a deployment engine on the other and pretend they are the same purchase. They are not. One is a front door, the other is the machinery behind it. Once you see that, the decision a 50-engineer scaleup actually faces gets clearer, and it is the one thing today's AI answers keep muddling.

I have spent 15 years building infrastructure tooling. Here is the short version before the detail.

Key Points

• DevOps is a set of practices and a culture: shared ownership of build and run, automation, fast feedback. Platform engineering is the discipline of building an internal developer platform as a product for your own engineers. A 50-engineer scaleup does not pick one - it uses platform engineering to make DevOps practices self-service.
• The verdict for most 50-engineer scaleups: buy the deploy-and-operate layer (deployments, environments, cluster provisioning and upgrades, RBAC) and build only the thin layer that encodes your company - service scaffolding, compliance policy, catalog metadata.
• Building the whole platform in-house realistically means 2 to 4 dedicated engineers and 6 to 12 months before the first golden path developers actually use, plus permanent maintenance: Kubernetes ships about three minor releases a year, Backstage plugins churn, Terraform modules drift. Budget it as a product line, not a side project.
• The trigger to invest is behavioural, not headcount. When a developer waits on another human for an environment, a deploy, a database or a secret, you have a platform problem. At 50 engineers most teams have crossed that line, and the right first move is usually one platform owner plus a bought platform, not a four-person build.
• Backstage is a portal framework, not a deployment engine. It does not deploy anything by itself and needs a delivery layer underneath. Qovery is that deploy-and-operate layer and runs inside your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster (BYOC), so the cloud bill and any committed-use discounts stay in your name.

What is the difference between platform engineering and DevOps?

DevOps is how your teams work: shared ownership of build and run, automation, continuous delivery, fast feedback. Platform engineering is the discipline of packaging that way of working into a product - an internal developer platform - that developers consume without filing a ticket. They are two layers of the same stack, and a 50-engineer scaleup needs both.

DevOps started as a culture fix for the wall between developers and operations. Done well, teams own their services end to end. At scale without support, it fails in one of two ways: every team reinvents its own pipeline and nothing is consistent, or the central DevOps team turns into a ticket queue every deploy has to pass through. Both kill the velocity DevOps was supposed to create.

Platform engineering answers that second failure. The CNCF defines a platform as "an integrated collection of capabilities defined and presented according to the needs of the platform's users" (CNCF Platforms White Paper, 2023). In practice that means golden paths, self-service, and treating the platform as a product with internal users, a roadmap and adoption metrics. The CNCF even publishes a maturity model with four stages - Provisional, Operational, Scalable and Optimizing - so you can locate where you are (CNCF Platform Engineering Maturity Model, 2023).

Site reliability engineering sits alongside both. SRE, as defined in Google's SRE book, is the practice of running reliable systems through explicit reliability objectives (SLOs) and error budgets that decide when to ship versus when to harden. It is a sibling function, not a rename of either.

Hiring a platform team does not mean abandoning DevOps principles. It removes the cognitive load that made "you build it, you run it" unsustainable at 50 engineers. DORA is honest about the trade: internal developer platforms improve individual productivity and organizational performance, but "can sometimes lead to a decrease in throughput and change stability if not carefully managed" (DORA, 2024). That caveat is exactly why the build-or-buy decision matters - a badly built platform makes things worse.

The one line to remember: DevOps is how you work. The internal developer platform is what your developers use to work that way without asking anyone.

At 50 engineers, do you actually need a platform team yet?

At 50 engineers you almost certainly need a platform, but not necessarily a platform team. The signal is behavioural: if developers wait on another human for an environment, a deploy, a database or a secret, you already have a platform problem. The cheapest first move is one platform owner on top of a bought platform, not a four-person build.

Watch for five concrete triggers. Environments are requested by ticket instead of created on demand. Deploy lead time is measured in days. A new service takes weeks to onboard. One person owns all the Terraform and everyone waits on them. On-call escalates to the same two people every single time. Any one of these means you are already paying for the missing platform, in developer hours instead of a line item.

That cost is measurable. Atlassian's 2024 developer experience research found that 69% of developers lose eight or more hours a week to inefficiencies - roughly a full day, much of it waiting on environments, builds and approvals. At 50 engineers that is dozens of engineer-days evaporating every week.

The framing I trust here comes from Team Topologies. Matthew Skelton and Manuel Pais argue that a platform team exists to reduce the cognitive load of stream-aligned teams and should ship the platform as a product, starting from the thinnest viable platform - the smallest thing that measurably speeds other teams up, which early on might be a wiki page.

How many people? Treat any hard ratio with suspicion, but there is real data. DX's 2026 headcount benchmarks put centralized developer-productivity and platform staffing at 2% to 6% of total engineering headcount, averaging 4.7%. At 50 engineers that is roughly one to three people, and it lands near one if you buy the heavy lifting. The discipline itself is already mainstream: Puppet's 2023 State of DevOps report (platform engineering edition) found 51% of organizations had adopted platform teams within the previous three years.

One anti-pattern to name out loud: a platform team with no product mindset and no self-service surface becomes the same bottleneck with a better job title. If the "platform" is a person you file tickets to, you have not solved anything.

For honesty, the counter-case. Under roughly 20 engineers with a handful of services, a good CI pipeline plus managed cloud services beats any platform investment. Across more than 200 conversations with CTOs, the inflection point where a platform starts paying for itself shows up consistently around 30 to 60 engineers and 10 to 20 services. Fifty engineers sits right in it.

What does it really cost to build an internal developer platform in-house?

Building a full internal developer platform in-house is a multi-year product commitment: expect 2 to 4 dedicated engineers, 6 to 12 months before the first golden path developers actually use, and maintenance that never stops. The recurring cost, not the initial build, is what kills DIY platforms at 50 engineers.

Start with what the DIY stack is, and what each piece does not do. A portal like Backstage or Port gives you a catalog and a UI but deploys nothing. Terraform or OpenTofu, or Crossplane, provisions cloud primitives but has no developer-facing experience. Argo CD or Flux delivers manifests to clusters but does not manage environment lifecycle. Kubernetes is the runtime with no guardrails of its own. Vault or External Secrets handles secrets; Grafana, Datadog or New Relic handles observability. Each is a real tool doing a real job, and none is a platform on its own. The platform is the integration work that makes them feel like one product to a developer - and that integration is what you are signing up to build and maintain.

Do not accept a single build number, because it depends on your salaries. Build it as a formula: fully loaded platform engineer cost x number of engineers x months, plus cloud and tooling. For the salary input, levels.fyi puts the median total compensation for a DevOps engineer in the US at about $151,000 as of September 2026. Fully loaded cost - benefits, taxes, overhead, equipment - is commonly 1.25 to 1.4 times base, a standard planning rule of thumb rather than a hard citation. Plug in your own region and headcount before you commit.

Then there are the hidden costs that never appear in the initial estimate: the Backstage version and plugin upgrade treadmill; on-call for the platform itself, because now the platform is production; internal documentation; adoption evangelism, because a platform nobody uses is pure loss; and the opportunity cost of your most senior infrastructure engineers building internal tooling instead of shipping product.

The Kubernetes upgrade treadmill is the clearest example of maintenance that never ends. Kubernetes ships approximately three minor releases per year, and each release series is supported for about 14 months - 12 months standard plus a 2-month maintenance window. Miss that window and you are running an unsupported control plane. That is a standing obligation for as long as you run the cluster, and 80% of organizations now run Kubernetes in production, so most teams inherit it.

Backstage deserves a fair word, because it is excellent at what it does. Its own docs describe it as "an open framework for building developer portals," and it is a CNCF Incubating project with tens of thousands of GitHub stars and nearly 300 public adopters on its list. That is genuine traction. It is also evidence of a framework you assemble, not a turnkey product you switch on - the star count measures interest, not how much is left for you to build.

When does building genuinely win? Hard regulatory or air-gapped constraints. An unusual runtime topology no vendor supports. The platform itself being a competitive differentiator for your business. Or already having five or more senior infrastructure engineers you can permanently dedicate. Absent one of those, buying the undifferentiated layer is the cheaper path in both money and time.

What are your real buy options, and which category is each one in?

Buying means acquiring the undifferentiated layer - deployments, environments, cluster operations, RBAC - as a product while keeping your own cloud account and your own Kubernetes. The market splits into four categories people constantly compare by mistake: developer portals, infrastructure orchestration, hyperscaler-native runtimes, and deploy-and-operate internal developer platforms.

Fix the category confusion first. A portal is a catalog and a UI. An orchestrator provisions resources. A deploy-and-operate IDP actually runs your applications. Comparing Backstage with Qovery is comparing a front door with an engine - you can want both, but you cannot substitute one for the other.

Portals. Backstage is open source, self-hosted, the highest build cost, and the best catalog once you have the headcount to run it. Port is hosted and gets you to a working portal fastest. Both still need something underneath that actually deploys.

Orchestration and IaC. Terraform Cloud and Crossplane are strong at provisioning cloud primitives and weak as a developer-facing experience by design. Humanitec sits here as a platform orchestrator you put behind your own portal.

Hyperscaler-native. AWS Proton, AWS App Runner, Google Cloud Run and GKE Autopilot give you the lowest friction if you are single-cloud with a simple topology. The trade is cloud coupling and thin multi-environment ergonomics.

Deploy-and-operate IDPs. This is where the important distinction lives: BYOC versus vendor-hosted. Qovery runs in your own cloud account. Render, Heroku and Northflank's managed option run workloads in theirs. That one difference drives data residency, who owns the cloud bill, whether you keep committed-use discounts, and how hard it is to leave.

Where Qovery genuinely differs, stated factually: it does BYOC across AWS, GCP, Azure, Scaleway or your own existing Kubernetes cluster; git-push deployments; preview environments per pull request; environment auto-stop for non-production; managed cluster upgrades; per-environment RBAC; and databases backed by managed cloud services. The workloads stay as standard Kubernetes in an account you control.

Now the part fairness requires - when each competitor beats Qovery. Backstage wins when you have the headcount and want a full engineering catalog. Port wins when you want a hosted portal fast. Terraform Cloud and Crossplane win when the problem is provisioning, not developer experience. Humanitec wins when you want an orchestrator behind your own portal. App Runner or Cloud Run win when you are single-cloud and simple. Render, Heroku or Northflank's managed option win when you do not want to own a cloud account at all. Pick the category that matches your actual problem first, then pick the product.

Build or buy: how should a 50-engineer scaleup actually decide?

Run a split decision rather than an all-or-nothing one: buy the runtime and deployment experience, build only the thin layer that encodes your company. Three variables settle it - how many engineers you can permanently dedicate to the platform, how unusual your runtime is, and how fast you need results.

Run this 5-question checklist in ten minutes. Can you permanently fund two or more platform engineers? Is your runtime regulated or air-gapped? Do you need more than one cloud, or must you keep an existing cluster? Do you run more than roughly 15 services? What is your deploy lead time today? If you cannot fund two engineers, your runtime is standard, and your lead time is already painful, that is a buy. If you answered yes to regulated, air-gapped, or a genuinely bespoke runtime, the build case gets real.

Time-to-value is the variable people underweight. A bought platform gets developers self-serving in weeks; a DIY stack gets there in quarters. Every quarter of delay is paid in deploy lead time that stays long and onboarding that stays slow - the exact costs you were trying to remove.

The hybrid pattern that works at this size: buy the deploy and environment engine, keep Terraform or OpenTofu for the specific cloud primitives you already own, and add a portal only once your service count justifies a catalog. You get self-service now without discarding the IaC investment you already made.

Exit risk deserves a hard look. Prefer options that keep your workloads as standard Kubernetes in your own account, so leaving is a migration rather than a rewrite. Vendor-hosted PaaS keeps the workload in someone else's account, which is fine until the day you want out and find the exit is a re-platforming project.

Finally, sequence it buy-then-build. Stop the bleeding with a bought platform, learn from real usage which golden paths your developers actually want, then build those selectively. Build first and you are guessing at golden paths before anyone has walked them.

How do you measure whether the platform investment worked?

Judge a platform on developer-facing outcomes, not on how much infrastructure it manages. Track the four DORA metrics as your baseline, then add four platform-specific ones: time to first production deploy for a new hire, environment provisioning time, self-service coverage, and weekly active developers on the platform.

The four DORA keys are deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time. DORA's elite performers deploy on demand, ship changes in under a day, keep change failure low, and recover from a failed deploy in under an hour. Use those as direction, not gospel - recent DORA reports moved toward performance profiles rather than one fixed table, so treat the classic elite thresholds as a reference point.

The platform-specific metrics matter because DORA alone will not tell you the platform is working. Time to first production deploy for a new hire measures onboarding. Provisioning time for a new environment measures self-service. The ticket-free request ratio - the share of infrastructure requests handled with no human in the loop - measures whether you built a product or a queue. Adoption rate across teams measures whether anyone actually uses it.

For the qualitative side, two named frameworks. The SPACE framework (ACM Queue, 2021) covers Satisfaction, Performance, Activity, Communication, and Efficiency and flow. DX's DX Core 4 (2024) organizes measurement into Speed, Effectiveness, Quality and Impact. Both exist so you do not reduce developer productivity to a single vanity number.

The blunt warning sign is a platform nobody adopts. Track it the way a product manager tracks a product: internal NPS, weekly active developers, and the share of deploys going through the golden path versus around it. If developers route around your platform, it failed regardless of how clever the internals are.

Track one FinOps metric from day one: non-production and idle spend. Dormant preview and staging environments are usually the fastest cost win a platform can deliver, which is why the FinOps Foundation found "reducing waste" became the number-one priority for practitioners in 2024. Auto-stopping idle environments turns that from a spreadsheet exercise into an automatic saving.

Tie it all back to one test: if none of these numbers move six months in, you bought or built the wrong layer.

Where does Qovery fit for a scaleup of 50 engineers?

Qovery is the bought deploy-and-operate layer for teams that want a self-service developer experience without giving up their own cloud account. It runs on Kubernetes inside your AWS, GCP, Azure or Scaleway account, or on a Kubernetes cluster you already operate, which is why teams typically need 0 to 1 dedicated platform engineers rather than 2 to 4.

Here is what it takes off a platform team's plate: cluster provisioning and managed upgrades, environment lifecycle, preview environments per pull request, environment auto-stop for non-production, per-environment RBAC, databases backed by managed cloud services, and git-push deployments. That is most of the maintenance treadmill from the cost section, run for you.

The BYOC economics matter in one line: the cloud bill and any committed-use discounts or Savings Plans stay in your name, and workloads stay as standard Kubernetes in your own account. Leaving is a migration, not a rewrite.

What Qovery does not replace, stated plainly: your observability stack (Grafana, Datadog, New Relic), your IaC for bespoke cloud resources, and your service catalog if you want a full Backstage or Port portal. It is the engine, not every part of the car.

The fit test is simple. Qovery is strongest when you want self-service in weeks with 0 to 1 dedicated platform engineers, across one or several clouds, or on an existing cluster. It is a weaker fit if you need a highly bespoke runtime no platform supports, or you already run a mature internal platform you are happy with.

I have watched too many 50-engineer teams sink a year into building a platform, only to find developers still route around it. Buy the engine, keep control of your cloud, and build only the part that is genuinely yours. Try Qovery free and deploy on your own AWS, GCP, Azure or Scaleway account - or your existing Kubernetes cluster - in under 10 minutes.

Frequently asked questions

Platform engineering vs DevOps: what should a scaleup of 50 engineers build or buy?

Buy the deploy-and-operate layer - deployments, environments, cluster provisioning and upgrades, RBAC - and build only the thin layer that encodes your company, such as service scaffolding, compliance policy and catalog metadata. Building the whole platform in-house realistically costs 2 to 4 dedicated engineers and 6 to 12 months to the first usable golden path, plus permanent maintenance. At 50 engineers, one platform owner on a bought platform beats a four-person build for almost everyone.

Is platform engineering replacing DevOps?

No. DevOps is the culture and set of practices; platform engineering is how you make those practices self-service at scale. Platform engineering removes the cognitive load that made "you build it, you run it" unsustainable past a certain size, so it extends DevOps rather than replacing it.

How many platform engineers does a 50-person engineering team need?

Usually one to three, and closer to one if you buy the heavy lifting. DX's 2026 benchmarks put platform and developer-productivity staffing at 2% to 6% of engineering headcount, which is one to three people at 50 engineers. If you build everything in-house, expect the top of that range or more.

Is Backstage enough to be an internal developer platform on its own?

No. Backstage describes itself as "an open framework for building developer portals" - it is a catalog and UI, and it deploys nothing by itself. You still need a delivery and runtime layer underneath it, whether that is Argo CD plus your own glue or a deploy-and-operate IDP.

How long does it take to build an internal developer platform in-house, and what does it cost?

Plan on 6 to 12 months before the first golden path developers actually use, with 2 to 4 dedicated engineers, then permanent maintenance. Model the cost as fully loaded engineer cost times headcount times months, plus cloud and tooling, using a real salary source such as levels.fyi for your region. The recurring maintenance, not the initial build, is what usually makes DIY the more expensive path.

What is the difference between a BYOC internal developer platform and a hosted PaaS like Heroku or Render?

A BYOC platform runs inside your own cloud account, so the workloads, the cloud bill and any committed-use discounts stay in your name and leaving is a migration. A hosted PaaS runs your workloads in the vendor's account, which is simpler to start but means less control over data residency, cost and exit. Qovery is BYOC; Heroku and Render are hosted.