Backstage Won the Portal War and Is Losing the Adoption War: What the 10% DIY Stall Really Costs

Backstage runs at more than 3,400 organizations, serves over two million developers outside Spotify, and holds roughly 89% of the internal developer portal market. It won its category so completely that "developer portal" and "Backstage" are nearly synonyms. And the average self-hosted Backstage instance is used regularly by about 10% of its intended developers.

That second number is the one that should set your budget. A portal nobody opens is not a platform; it is a very expensive internal website. This post prices the gap between the two numbers — what 6 to 12 months of DIY portal assembly actually costs in engineer-years and dollars — and sets it against the alternative the stall keeps pointing at: a deploy API whose golden path ships on day one instead of arriving a year later as a template inside a portal.

The paradox in two numbers​

The 89% figure comes from Roadie's January 2026 Backstage guide: 3,400+ adopting organizations, 2M+ developers outside Spotify, 89% share among internal developer portal frameworks. The 10% figure comes from the other end of the same ecosystem — 2026 platform-engineering commentary converging on the same warning, summarized bluntly by WebProNews' "AI Forge" piece: DIY Backstage efforts "often stall at 10% adoption after 6-12 months of maintenance hell."

Spotify itself is the exception that proves the rule. Inside Spotify, Backstage adoption sits at 96%+ of R&D staff, and onboarding time fell 55% measured to the tenth merged pull request. Outside Spotify, the average hovers around one-tenth of the engineers it was built for.

The difference is not the software — it is the team behind it. Spotify staffs Backstage like the product it is. Most adopters staff it like the side project they hoped it would be.

Price the stall: what 6-12 months of DIY actually costs​

Backstage begins as a blank canvas, so "adopting" it really means building an internal product on top of a framework. Roadie's cost analysis, drawn from hundreds of implementations, puts the minimum viable self-hosted setup at 3 full-time engineers in year one and 2 FTEs in ongoing maintenance years, with 6 to 12 months before a production rollout earns regular use. Organizations that end up satisfied with self-hosting typically dedicate somewhere in the 3-to-12 FTE range. Port's ROI analysis independently lands in the same territory: up to 12 months before the catalog and self-service actions deliver enough value for engineers to use the portal habitually.

Convert that to dollars. The fully loaded cost of a senior platform engineer runs roughly $125,000 (Roadie's 2025 figure for top tech hubs) to $150,000–$180,000 (current US median). So the minimum-viable DIY year costs:

• Floor: 3 FTEs × $125K = $375,000 before infrastructure or opportunity cost
• Typical: 3–5 FTEs × $150K–$180K = $450,000–$900,000 for year one
• Satisfied-at-scale: up to 12 FTEs, pushing past $1M/year in engineering time alone

Now put the same team sizes next to the two alternatives — a managed Backstage and a golden-path-first deploy API:

Read the table with its caveat attached: vendor-published FTE figures are directional, not independently benchmarked, and a disciplined small team can run a lean Backstage below these bands. But the orders of magnitude are the point. The DIY portal costs two orders of magnitude more than the managed version of itself in year one — and its modal outcome is a portal one developer in ten opens. The deploy API column has no adoption row because there is nothing to adopt: every deploy travels the golden path by construction.

Sensitivity check: even if you halve the loaded cost (non-hub salaries, partial allocation) and hit the optimistic 6-month rollout, the DIY floor is still ~$190K and half a year before the portal earns its first habitual user. There is no reasonable input set where "assemble a portal" is the cheap way to get developers deploying faster.

Why the stall happens: a framework, not a product​

Four concrete drivers show up in nearly every DIY post-mortem:

1. The blank canvas. Backstage ships no catalog content, no templates, no integrations — your services, docs, and CI/CD wiring all arrive via months of YAML authoring and plugin configuration. Port's analysis notes that manual data ingestion through YAML files is where catalog maintenance starts rotting the moment the initial enthusiasm fades.

2. The plugin treadmill. The ecosystem is Backstage's greatest strength and its heaviest tax. Every plugin is a dependency with its own upgrade cadence, and the portal team owns the integration matrix across Backstage core upgrades. Community estimates put ongoing maintenance at 2–5 full-time engineers minimum, rising to 15 at enterprise scale.

3. The React/TypeScript tax. Real customization means writing React and TypeScript against Backstage's extension APIs — theming, custom components, bespoke plugins. The CNCF's Certified Backstage Associate exam explicitly tests React code modifications and Material UI theming, which tells you what "adopting" the framework actually demands of the team.

4. Adoption is opt-in. A portal is a destination developers must choose to visit. A deploy pipeline is a path they cannot avoid. Every DIY portal competes for attention against the CLI and IDE workflows developers already have, which is exactly why external adoption averages 10% while Spotify — where Backstage is wired into hiring, environments, and daily workflow — holds 96%+.

What golden paths actually buy (the win is the path, not the portal)​

Here is the uncomfortable detail for portal-first thinking: every celebrated Backstage outcome is a golden-path win, not a catalog-browsing win. Spotify's 55% onboarding reduction came from scaffolded services landing in staging with CI/CD, monitoring, and policy already wired. Chicago Trading Company saved 18 months of developer time in ten months through templatization — golden-path scaffolding plus feedback loops.

A global fintech cut service onboarding from three weeks to two hours with Golden Paths. American Airlines' Runway platform deploys in under six minutes.

Nobody's case study says "developers now enjoy browsing the catalog." They all say some version of "the template deploys the thing." The portal is the shelf; the golden path is the product. Teams that bought the shelf and never stocked it got the 10% outcome. Teams asking what to build first should notice which half produces every number anyone brags about.

The inversion: a deploy API is a pre-shipped golden path​

Compare what each approach asks a new engineer to do on day one:

• Backstage golden path (you build it): scaffold from a template your platform team wrote, which provisions a repo, wires CI/CD, registers the service in the catalog, and deploys — after 6–12 months of platform-team work to create the template, the actions, and the portal around it.
• Deploy API (shipped on day one): git push a repo; get a running HTTPS service with builds, TLS, routing, and logs. The golden path is the only path, so adoption is 100% of deploys by definition.

The PaaS version is not a lesser golden path. Heroku proved the shape in 2010 — opinionated, self-service, no humans in the loop — and Render-style platforms kept it: setup in minutes, auto-deploys from git, free TLS. What the portal adds on top (ownership metadata, scorecards, tech-docs search) is real but secondary; what the deploy path delivers (a service running in production today) is the outcome every onboarding metric actually measures. Note the advice from teams that build IDPs from scratch: measure success by time-to-first-deploy for new services, not portal adoption metrics. The deploy API optimizes the recommended metric directly.

This is also why the stall is so punishing as a sequencing error. A team that ships the deploy path first gets the golden-path win in week one and can add a catalog later from a position of strength — with real services, real owners, and real usage data to ingest. A team that builds the portal first spends a year assembling the shelf, discovers 10% adoption, and still has no faster deploy path than when it started.

When Backstage still wins: the honest counter-case​

None of this means Backstage is a bad bet at every scale — it means it is a late bet, not an early one. The portal earns its cost when the problems it solves actually exist:

• Service sprawl past human memory. Expedia runs ~20,000 microservices across 15+ brands for 5,000+ developers. Nobody finds anything at that scale without a catalog. A 30-service startup does not have this problem.
• Compliance and standards enforcement. Scorecards, ownership metadata, and audit trails pay for themselves under regulatory pressure. Toyota's $10M in savings from its platform work is the shape of ROI that justifies portal staffing.
• Multi-platform sprawl. When workloads span several clouds, clusters, and legacy estates, a unified front door beats five consoles. A single PaaS with one deploy API does not need a front door.

The pattern across the wins: Backstage pays off after a team has many services, many developers, and a staffed platform org — roughly the profile of the organizations in the satisfied 3-to-12-FTE band. Building it before you have those is buying the observatory before you have the telescope.

Path first, portal later (maybe)​

If you are deciding build order this quarter, four questions settle it:

1. How many services? Under ~100, a catalog page is a luxury; a faster deploy path is a raise for every engineer.
2. How many platform engineers? Under 3 dedicated, DIY Backstage is the abandoned-demo failure dominating 2026 post-mortems. Staff the path instead.
3. What is time-to-first-deploy today? If a new service still needs tickets and manual pipeline setup, that gap — not portal adoption — is the metric to move.
4. Is anyone asking for a catalog? "Where do I find X" pain at scale is the legitimate trigger for Backstage. Absent that pain, the portal is a solution waiting for a problem.

The 89% market share tells you Backstage is the safe choice when you need a portal. The 10% adoption stall tells you most teams buy it before they need one — and pay $375K+ and a year to learn that the golden path was the product all along. Ship the path first. If you ever outgrow it, the portal will still be there, and you will finally have something worth cataloging.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.