Building an internal developer platform costs more than buying one until you are well past 100 engineers — and the gap is headcount, not licence fees. Self-hosting Backstage typically needs two to four dedicated engineers, which lands between $450,000 and $800,000 in year one and $250,000 to $450,000 every year after. A commercial IDP at the same headcount usually costs a fraction of that. This guide runs the real numbers for both routes, shows where the crossover actually sits, and covers the hybrid and partner-led options most build-vs-buy comparisons skip.
That framing is the opposite of how most teams approach the build or buy IDP decision. Backstage is free to download, so it looks like the cheap option. The licence is the only part of the cost that is actually zero, which is why the honest answer to "how much do internal app platforms cost" starts with people rather than software.
What Is an Internal Developer Platform?
An internal developer platform (IDP) is a self-service layer between developers and infrastructure. Instead of filing tickets for a database, waiting on DevOps for an environment, or hand-assembling CI/CD for every new service, developers work through the platform: it provisions, deploys and surfaces observability according to standards your organisation defines. That is the key distinction in internal developer platforms vs cloud platforms: AWS, Azure and GCP provide the infrastructure itself, while an IDP sits on top of them and packages that infrastructure into self-service workflows your developers can use without tickets.
The distinction matters because the two are often confused in budget conversations. A cloud platform bills you for compute, storage and managed services, and it exposes thousands of primitives that every developer would otherwise need to understand. An internal developer platform does not replace any of that; it narrows it. The platform team decides which of those primitives your organisation actually uses, wraps them in templates and guardrails, and presents a much smaller surface to the people shipping features. When you compare internal developer platforms vs cloud platforms, the cloud is the raw material and the IDP is the factory floor built on top of it.
Platform engineering — the discipline that produces IDPs — has moved from trend to default: Gartner has projected that a large majority of software engineering organisations will run internal platform teams by the late 2020s. The question in 2026 is no longer whether an IDP matters, but how you acquire one, which is why the IDP build or buy question now comes up so early in platform planning.
What You Are Actually Choosing Between
Framing it as a build vs buy IDP system decision implies two options. There are three, and the middle one is the route most teams overlook.
| Route | What it means | Best when |
|---|---|---|
| Build | Self-host Backstage or assemble your own platform from open-source parts | You have a platform team already, and the platform is a genuine differentiator |
| Buy | Commercial IDP — Port, Cortex, Atmosly and others, priced per seat | You need value in weeks, and your problems are the same as everyone else's |
| Partner | Someone builds it with you, then hands over or keeps running it | You want to own the stack but do not want to hire a platform team to get there |
| Platform | Indicative pricing | Notes |
| Port | ~$20–50 per user/month | Free tier at low seat counts; enterprise tiers from ~$30+ |
| Cortex | ~$20–65 per user/month | The higher figure is from the Forrester Total Economic Impact study (July 2024) at scale |
| OpsLevel | ~$20–40 per user/month | Scorecard-led positioning |
| Humanitec | ~$15–40 per user/month | Orchestration-led rather than portal-led |
| Build | Buy | |
| Time to value | 3–6 months to production value is typical for Backstage; often longer | 2–4 weeks for a per-seat product |
| Up-front cost | $450K–800K year one at typical mid-size scale | Low — per-seat, often with a free tier |
| Cost at 1,000 engineers | Roughly flat platform-team cost, plus plugin maintenance | $240K–780K/yr depending on seat price |
| Customisation | Unlimited — you own the code | Bounded by the vendor's data model and APIs |
| Maintenance | Yours, permanently — upgrades, plugins, security | Vendor's job; you configure rather than operate |
| Lock-in | To your own past decisions and the people who made them | To the vendor's schema and pricing at renewal |
| Skills needed | TypeScript/React for Backstage, plus platform ops | Configuration and integration skills |
| Engineering headcount | What usually makes sense | |
| Under 20 | Buy — or wait. A dedicated platform team costs more than any tool you would buy, and you probably do not need one. | |
| 20 – 100 | Buy or partner. Building rarely pays back at this size, and the engineers you would assign are usually your best ones. | |
| 100 – 300 | Genuinely depends. The question is whether you can spare three engineers permanently, not whether you can spare them for the build. | |
| 300+ | Build or hybrid becomes defensible — if the platform is a differentiator rather than plumbing. | |
| Capability | What it does | How hard to build |
| Service catalogue | Who owns what, what depends on what, where the runbook is | Easy to start, hard to keep accurate |
| Golden paths | Templated ways to create a new service that carry your standards | Moderate — the templates are the easy part, adoption is not |
| Environment provisioning | Self-service ephemeral or per-team environments | Hard, and where most homegrown platforms stall |
| Scorecards | Measuring services against standards — coverage, ownership, security | Moderate, but worthless without accurate catalogue data |
| Cost visibility | Which team, service or environment is spending what | Hard to do at Kubernetes granularity |
The Build Route: What Backstage Really Costs
Backstage is the default answer when a team decides to build, and for good reason. It is open source, backed by the CNCF, has a large plugin ecosystem, and Spotify runs it at a scale most organisations will never reach. None of that changes the economics. The software is free; running it is not.
The realistic floor for a self-hosted Backstage deployment is two dedicated engineers, and most mid-size organisations end up at three or four once the catalogue, templates and custom plugins are in production. At a loaded cost of $150,000 to $180,000 per engineer, that is $300,000 to $720,000 in salaries alone before you count the three to six months when the platform exists but is not yet delivering value. Add infrastructure, tooling and the inevitable consulting engagement when the first upgrade goes wrong, and $450,000 to $800,000 for year one is a conservative mid-size estimate. Years two onward settle at $250,000 to $450,000, because the team does not go away. Upgrades land every few weeks, plugins break on each one, and the catalogue drifts out of date the moment nobody is paid to keep it accurate.
The engineers you assign matter as much as the number. Building a platform requires TypeScript and React for the Backstage front end, Node for the backend, Kubernetes operations for the runtime, and enough product sense to drive adoption across teams who did not ask for a new tool. Those are usually your most senior people, which means the opportunity cost is the feature work they are no longer doing. That hidden line is the one most IDP build-or-buy spreadsheets leave blank.
The Buy Route: Per-Seat Pricing and What It Hides
Commercial IDPs invert the cost curve. Instead of a large fixed headcount cost that stays flat as you grow, you pay a small per-seat fee that grows with you. At $20 to $65 per user per month, 100 engineers cost $24,000 to $78,000 a year, which is less than a single platform engineer. At 1,000 engineers, the same pricing becomes $240,000 to $780,000, which is roughly what a platform team costs. That is the entire shape of the build vs buy IDP system decision: buying is cheaper until your headcount makes the licence bill look like a salary bill.
What per-seat pricing hides is the configuration effort. A commercial product delivers a working catalogue in two to four weeks because it ships with integrations for GitHub, Kubernetes, PagerDuty and the rest, but someone still has to connect them, define the data model, write the scorecards and build the self-service actions your developers will actually use. That is typically half an engineer on an ongoing basis, not zero. The other hidden cost is the renewal: once your catalogue, templates and scorecards live in a vendor's schema, the price at year three is set by the vendor, and the cost of leaving is the cost of rebuilding all of it somewhere else.
The products differ in where they put their weight. Port leads with a flexible data model and self-service actions; Cortex and OpsLevel with scorecards and service maturity; Humanitec with orchestration of environments rather than a portal. Atmosly packages the Kubernetes layer — environments, deployments, cost — alongside the portal. The right choice depends less on feature lists and more on which of the five capabilities below is your actual bottleneck.
Where the Crossover Sits by Team Size
The headcount table above is the practical summary, and it is worth explaining why the bands fall where they do.
Below 20 engineers, the problem an IDP solves barely exists. Everyone knows who owns what, environments are few, and a well-maintained set of templates in your repositories does most of what a platform would. A platform team at this size costs more than the entire engineering function's tooling budget. Buy if a free tier covers you, or wait.
Between 20 and 100 engineers, the pain becomes real — onboarding slows, ownership blurs, environments multiply — but the arithmetic still favours buying or partnering. A built platform at $450,000 to $800,000 in year one is a large fraction of the total engineering payroll, and the people you would assign to it are the ones you can least afford to lose from product work. Per-seat pricing at this size is a rounding error by comparison.
Between 100 and 300 engineers, the IDP build or buy decision stops being obvious. Per-seat pricing is now $36,000 to $234,000 a year; a platform team is $250,000 to $450,000, and the gap is narrow enough that customisation needs and existing skills can swing it. The honest test is not whether you can spare three engineers for six months to build it, but whether you can spare them permanently. If the answer is no, buy or go hybrid.
Above 300 engineers, building or hybrid becomes defensible on cost alone, and the deciding factor shifts to whether the platform is a differentiator. If your deployment model, compliance requirements or multi-cloud topology are unusual enough that no vendor's data model fits, the flexibility of owning the code pays for itself. If your needs look like everyone else's, you are paying a platform team to rebuild what you could license.
What an IDP Actually Needs to Include
Whichever route you take, the capability table above is the checklist, and the "how hard to build" column is where homegrown platforms get into trouble.
The service catalogue is the foundation and the easiest thing to start: a YAML file per service listing owner, dependencies and runbook. It is also the hardest thing to keep accurate, because the moment it drifts, every scorecard built on it reports fiction and developers stop trusting the platform. Golden paths — templated service creation carrying your standards for CI/CD, observability and security — are moderate to build but hard to get adopted, because a template nobody uses is just documentation.
Environment provisioning is where most built platforms stall. Self-service ephemeral or per-team environments on Kubernetes require orchestration, cost controls, secrets handling and teardown logic that Backstage does not provide out of the box; this is the capability that separates a portal from a platform. Cost visibility at the team, service and environment level is similarly hard at Kubernetes granularity, and it is the capability finance teams ask for first when they want to know how much internal app platforms cost in practice, rather than on the licence invoice.
The Hybrid Route Most Comparisons Skip
Hybrid means buying a commercial product, or adopting an open-source core, for the undifferentiated capabilities — catalogue, portal, templates, scorecards — and building only the parts that are genuinely specific to your organisation through the platform's plugin and API surface. You get most of build's flexibility at something closer to buy's cost, and you avoid spending senior engineers on a service catalogue that looks identical to every other company's.
The precondition is a real extension model. A platform whose catalogue data, templates, and configuration live in standard, portable formats can be extended today and migrated tomorrow; one that stores them in a proprietary schema turns hybrid into lock-in with extra steps. You still need one or two engineers to own the extensions and drive adoption, which is why hybrid is cheaper than build but not free.
The Partner Route: Owning the Stack Without Hiring the Team
The third option is the one most comparisons leave out, because most comparisons are written by vendors selling a product or by platform engineers justifying a team. A partner-led build means an experienced platform engineering team builds the IDP with you — usually on Backstage or a commercial core, on your infrastructure, in your repositories — then hands it over or keeps running it.
The economics sit between the other two routes. An assessment typically runs $10,000 to $15,000, an MVP $40,000 to $80,000, and a full multi-team rollout $80,000 to $200,000 or more. Against $450,000 to $800,000 for a self-directed year one, the savings are partly engineering hours and mostly the institutional knowledge of having done it before: which plugins break on upgrade, which catalogue structure survives contact with real teams, how to get the first three teams onto golden paths before the platform loses momentum. The trade-off is that you still need someone internal to own it afterwards, even if that is half an engineer rather than three.
How to Make the Decision
Run the build vs buy IDP system decision as a three-year calculation at the headcount you expect, not the one you have, because per-seat pricing grows with your team and a platform team's cost does not. Name the specific people who will maintain a built platform in year three; if you cannot, you are not ready to build. List the customisations you truly need and strike out the ones a commercial product already covers — the list is usually shorter than it looks. Check exit options before signing anything, so that whichever way the build or buy IDP answer falls today, you can change it later without a rewrite. And if it is still unclear whether the platform team should be a separate function from DevOps and SRE, that question is worth settling first, because it decides who owns the platform in year three.
Platform builds rarely fail during the build. They fail eighteen months later, when the engineers who understood the platform have moved on, the version is several releases behind, and nobody wants to own the upgrade. Whatever route you choose, the question to answer first is not what it costs to build, but who maintains it in year three.
