Build vs. Buy: Choosing Your Internal Developer Platform in 2026
Most teams reaching 40–80 engineers hit the same conversation: "Should we build our own developer portal, or buy something?" It sounds like a tooling question. It isn't. It's a question about where your engineering capacity should go for the next 12–18 months. The wrong call doesn't just waste money, it burns out the platform team, delivers late, and still doesn't solve the underlying problem. This post gives a neutral framework, not vendor-backed, not theoretical, for making it well.
Key Takeaways
- In 2026, Backstage has over 3,000 adopters and ranks as the #5 CNCF project by velocity, but external teams report average internal adoption of only 10% (OpsLevel, 2025).
- Building from scratch is almost never justified below 150 engineers. The maintenance cost, not the build cost, is what kills teams.
- In 2025, 58% of developers said they lose at least 5 hours per week to unproductive work, an IDP should fix that, not add to it (Port, State of Internal Developer Portals, 2025).
What Is an Internal Developer Platform?
An IDP is the collection of tooling, interfaces, and workflows that lets product engineers self-serve infrastructure operations like spinning up environments, checking deployment status, and managing service configuration, without filing a ticket or interrupting a platform engineer. In 2025, Port's State of Internal Developer Portals found that 58% of developers lose at least 5 hours per week to unproductive work, with the most common culprit being tool sprawl and unclear self-service paths (Port, 2025). A well-designed IDP is the fix.
From practice: At Deliveroo, the pain point wasn't that developers couldn't provision infrastructure, it was that they didn't know whose job it was to ask. Tickets bounced between teams. An IDP clarifies ownership and removes that ambiguity, whether you build it or buy it.
The key distinction: an IDP isn't a single product. It's a capability. You can deliver it with a polished commercial portal, a Backstage instance with ten plugins, or a curated set of Terraform modules and a service catalogue in Notion. The question isn't "portal or no portal?", it's "how much investment does this capability warrant right now?"
For a broader introduction to building the platform team and processes before the portal, see the platform engineering playbook.
The 2026 Landscape: What's Actually Available?
The IDP market has matured significantly. The global internal developer portal market reached USD 2.34 billion in 2024 and is projected to grow at 21.7% CAGR through 2033 (Growth Market Reports, 2024). That growth has produced three distinct categories, each with a different total cost of ownership.
Build from scratch. A custom portal with custom APIs and integrations, built entirely in-house. Full control, maximum cost, maximum flexibility. Zalando spent over $4 million across four years before open-sourcing their platform work. That's the real baseline for "from scratch."
Open source (assemble yourself). Backstage is the dominant option here, a CNCF-graduated project with over 3,000 adopters and 2,000 contributors (CNCF, 2024). Port and Cortex are lighter-weight alternatives that blur the line between open-source and commercial. Each requires significant ongoing investment to operate at production quality.
Commercial platforms. Humanitec (platform orchestration focus), OpsLevel (service maturity and catalog), and Compass (Atlassian's portal for teams already in the Jira ecosystem). Faster time to value, less flexibility, vendor dependency.
From practice: I've seen this pattern repeatedly, a team of 80 engineers, excited about Backstage, dedicates two engineers to set it up. Six months later, those two engineers are still full-time on Backstage, the plugin backlog keeps growing, and product engineers still aren't using it. Backstage's plugin ecosystem is vast but quality is uneven. At that team size, the cost of maintenance frequently exceeds the original build cost within 18 months.
According to Humanitec's State of Platform Engineering Volume 3, 56% of platform teams surveyed have existed for fewer than two years, which means most teams are still in the experimental phase of their IDP journey, not yet at the maintenance reckoning (Humanitec, 2024).
What Does Building Your Own Actually Cost?
Building from scratch is expensive in ways that rarely appear in the initial estimate. A basic portal, service catalogue, environment provisioning, deployment status, takes a 2–3 person team between 3 and 6 months to deliver something product engineers will actually use. That's 6–18 engineer-months before anyone outside the platform team sees value. According to a 2026 analysis by platformengineeringcost.com, ongoing maintenance runs at 20–40% of initial build cost per year, meaning a portal that cost $600k to build costs a further $120–240k annually just to keep current (platformengineeringcost.com, 2026).
The hidden costs are what bite teams hardest. Upstream Backstage releases roughly every two weeks. Keeping a custom fork current is a full-time job. Community plugins frequently go unmaintained. Security patching falls to whoever built the internal fork, not a commercial vendor. And as your organisation grows, the portal needs to grow too, which means the build never really ends.
The teams that handle build-from-scratch well share one characteristic: they treat the platform as a product, with a dedicated team of at least 3–4 engineers, a product roadmap, and a feedback loop with internal users. Teams that treat it as a project, a thing that gets built and handed over, almost always underestimate the ongoing cost.
What Does Open Source (Backstage) Actually Cost?
Backstage is free to use but not free to run. A Backstage instance serving 100 engineers typically requires 0.5–1 FTE dedicated to maintenance. That's before you count the time engineers spend evaluating, installing, and debugging plugins. The CNCF's 2024 Annual Survey placed Backstage in the 'Adopt' position of its technology radar, confirming it as the category default (CNCF Annual Survey 2024, 2025). The problem isn't legitimacy, it's ongoing effort.
The plugin ecosystem spans over 1,000 community contributions. Quality varies dramatically. A plugin that works for a team of 20 at a startup may not hold up at 200 engineers, and the burden of vetting falls entirely on you. OpsLevel's analysis found that despite Backstage's 99% adoption rate at Spotify, external teams average only 10% internal developer adoption. The portal exists, but engineers don't use it (OpsLevel, 2025).
Self-hosting adds infrastructure cost on top: Kubernetes cluster for the app and search backend, a managed database, observability tooling. For a 100-engineer team, that's typically $2–4k/month in cloud spend before any engineering time.
For a practical look at how to structure the platform team that would own this, see platform team topologies and structure.
What Do Commercial Platforms Cost?
Commercial platforms trade customisation for speed and reduced maintenance load. Compass (Atlassian) starts at approximately $7 per user per month on its standard plan. That's around $4,200/month for 75 engineers, or roughly $50k/year before enterprise discounts. Humanitec and OpsLevel are enterprise-priced, typically negotiated per seat or per service, and commonly land in the $80–200k/year range at 75–150 engineers. That sounds expensive until you compare it with the FTE cost of owning Backstage.
The real trade-off isn't cost, it's customisation. Commercial platforms give you 80% of what most teams need, fast. If your platform requirements are fairly standard (service catalogue, deployment tracking, environment management), commercial options will deliver value within weeks. If you have genuinely unusual workflow requirements, or you're building a product on top of your platform that requires deep integration, commercial limits become real constraints.
Vendor dependency is the other consideration. If your commercial provider raises prices, changes their product, or folds, your team needs a migration plan. That's a meaningful risk. It's manageable, but it needs to be factored in.
The Decision Framework: A Team-Size Guide
Team size is the most reliable signal for which path makes sense, not because it's a perfect proxy, but because it correlates with the two things that actually matter: maintenance capacity and complexity of requirements.
Under 30 engineers. Don't build an IDP. The problem isn't the portal, it's the missing platform foundation. Invest in CI/CD reliability, basic observability, and IaC standardisation first. An IDP built on shaky foundations gives you a nice UI for a broken system.
30–75 engineers. Use lightweight tooling only. A curated Terraform module library, a simple service catalogue (even a well-maintained Notion page), and documented runbooks. Backstage is almost certainly overkill. Commercial portals are probably also premature.
75–150 engineers. This is where Backstage or a commercial option makes sense. The pain is real enough to justify the investment, but building from scratch is almost never worth it at this scale. You don't have the maintenance capacity.
150+ engineers. A custom or highly customised open-source platform is now justified. You have the engineering capacity to maintain it, requirements are genuinely differentiated, and the platform is a competitive advantage in engineering hiring and productivity.
From practice: The most common mistake I see is teams at 60–80 engineers deciding to build from scratch because they want "full control." They don't need full control. They need something that works reliably by next quarter. Building from scratch at that scale almost always means the portal is 80% complete for 18 months and partial portals are worse than no portal, because they create confusion about what's official.
The Neutral Verdict: When to Build, When to Buy
Build your own IDP only if three conditions are true simultaneously: you have requirements that no existing platform covers (this is genuinely rare), you have the maintenance capacity, meaning dedicated engineers who aren't also on-call for production, and building is itself a competitive advantage for your business.
The case for open source or commercial is stronger for most teams: faster time to value, lower maintenance burden, and no need to reinvent solutions to solved problems. By 2028, Gartner estimates that 85% of organisations with platform engineering teams will provide internal developer portals, up from 60% in 2025 (Gartner, 2025). Most of those teams won't build from scratch.
| Factor | Build | Open Source | Commercial |
|---|---|---|---|
| Time to value | 6–18 months | 2–6 months | Days–weeks |
| Customisation | Full | High | Medium |
| Maintenance cost | High | Medium–High | Low |
| Team size fit | 150+ | 75–150 | 30–150 |
| Vendor risk | None | Low (OSS) | Medium |
For the CI/CD and infrastructure foundation you need before any portal investment, see CI/CD pipeline scaling guide.
Frequently Asked Questions
Is Backstage worth it for a 50-engineer team?
Probably not yet. Backstage requires 0.5–1 FTE to maintain and serves 100 engineers well, but at 50 engineers the overhead-to-value ratio is poor. A lightweight service catalogue and documented runbooks will solve 80% of the same problems. Revisit Backstage at 80–100 engineers when the pain clearly justifies the maintenance commitment.
What's the biggest hidden cost of building a developer portal?
Keeping up with upstream changes. Backstage releases every two weeks. Community plugins go unmaintained. Security patches are your problem. For a custom-built portal, the ongoing cost typically runs 20–40% of the original build cost per year, a number that rarely appears in the initial business case and frequently surprises engineering leadership twelve months later.
Can we start with a commercial platform and migrate to open source later?
Yes, and this is a reasonable path for many teams. Commercial platforms let you validate which capabilities your developers actually use before investing in a custom build. The migration cost is real, typically 3–6 months of parallel running, but you'll arrive at your open-source implementation with far better requirements than you'd have had starting from scratch.
What should we build before we worry about a developer portal at all?
Reliable CI/CD, basic observability (logs, metrics, alerts that wake the right person), infrastructure-as-code for environment provisioning, and clear service ownership. A portal built on top of these primitives delivers genuine self-service. A portal built without them is a UI for a process that still requires human intervention at every step.
How do I make the business case for an IDP investment?
Start with developer time. If 58% of your developers lose 5+ hours per week to unproductive work (Port, 2025), and your average senior engineer costs $180k/year fully loaded, five hours per week per engineer represents roughly $22k in lost productivity per engineer annually. Multiply by headcount, apply a conservative 20% recovery rate from an IDP, and you have a number that's usually larger than the platform investment.
Conclusion
The answer for most teams is: don't build your own until you have the capacity to maintain it. Start with what solves the most common pain, usually documentation, CI/CD, and service ownership clarity, before reaching for a portal. Add complexity when the pain demands it and the team can sustain it. The best IDP is the one your developers actually use, and that's almost always the simplest one that meets today's needs.