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 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.
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. The goal is lower cognitive load for developers and consistent guardrails for the platform and operations teams.
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.
What You Are Actually Choosing Between
The build-versus-buy question 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 |