The "is Backstage worth it" debate is always about cost: how many engineers, how many months, how much it runs per developer. The person who runs Backstage at Spotify will tell you that's not where it dies.
At BackstageCon, and again in an interview with The New Stack, Helen Greul, who heads Backstage engineering at Spotify, gave a number that should reframe the whole question. Outside Spotify, the average Backstage adoption rate is stuck at around 10%. Inside Spotify it is 99%. And the reason she gave for the gap was not that teams cannot afford the setup. It was that adopters often do not get past the proof of concept, because they never pinned down the problem their developers actually had.
Read that twice. The person responsible for Backstage at the company that invented it is telling you the tool usually fails after the hard engineering is done, not before.
That is worth sitting with, because almost every "is Backstage worth it" debate I see is an argument about the part Greul says is not the problem. Someone quotes the community estimate of around $150,000 per 20 developers in total cost of ownership. Someone else points out it takes two or three full-time engineers and the better part of a year to stand up a real catalog. Both numbers are accurate. Neither one answers the question, because cost tells you what it takes to build Backstage, and worth is decided by whether anyone uses what you built.
The question everyone asks, and the one that decides it
"Worth it" is a ratio. Value returned over what it costs you. The cost side is well documented and not in dispute. The value side is the part that quietly determines the outcome, and value from a developer portal is not delivered at launch. It accrues every time an engineer opens the portal instead of asking in Slack, trusts what it tells them, and acts on it. That only keeps happening if the portal keeps being right.
So the honest worth-it question is not "can we afford to build it". Plenty of teams can. It is "once we build it, will it stay true enough that people keep coming back". The 10% number is the industry's answer to that question, aggregated across thousands of organisations, and it is not flattering. The build is the table stakes. The trust loop is the game.
This reframe also explains a finding that looks paradoxical otherwise. Roadie's 2025 State of Backstage Report, drawn from 105 active practitioners, found that 70% of the companies that describe themselves as very happy with Backstage still dedicate at least three full-time engineers to maintaining it. The happy teams are not the ones who escaped the cost. They are the ones who pay it indefinitely and consider it worth paying, because for them the loop holds. The question is what makes it hold for them and break for everyone else.
Why Spotify gets 99% and you might get 10%
The most useful answer I have found comes from a Backstage founder describing, in an InfoQ talk, why Spotify's catalog stayed relevant when so many copies of it rot. The discipline was simple to state and hard to sustain. The metadata for each component lives in that component's repository, and ownership of the metadata is handed to the team that owns the component. The catalog is not a thing a central team curates. It is a thing every team is on the hook for, next to the code, as part of shipping.
That is the engine under the 99%. When the data lives where the work happens and the people doing the work own it, the data stays current, so the portal stays trustworthy, so people keep using it, so keeping it current stays worth their while. The loop reinforces itself. Break any link and it runs the other way. The data drifts, the portal gets a reputation for being wrong, people stop checking it, and the team maintaining it is now grooming a graph that nobody trusts. That is what 10% looks like from the inside. Not a portal nobody built. A portal nobody believes.
I want to be fair here, because this is where the critics get lazy. When the loop holds, Backstage is genuinely excellent, and the market reflects that. It holds roughly 89% of the internal-developer-portal market as of early 2026, serving thousands of organisations and millions of developers, and the data from teams who run it well is mostly positive. The plugin ecosystem is unmatched and the CNCF governance means it will outlast any single vendor. Backstage is not a bad tool. It is a tool whose worth is unusually sensitive to one variable, and that variable is whether the data inside it maintains itself or has to be maintained.
The diagnostic: does this fact maintain itself, or does someone have to?
This gives you a way to predict your own outcome before you spend a quarter finding out. Take the things you want to put in the portal, and for each one ask a single question. Does this fact stay current as a byproduct of how engineers already work, or does it require a separate act of maintenance that nobody is specifically paid to perform?
Some facts pass easily. Who owns a service. Who is on call. Where the runbook is. What the tech-docs say. The scorecard criteria your platform team defined. These originate with people, they change rarely, and a human decides them on purpose. The catalog model fits them well, because the catalog is the source of truth for that kind of data. There is no other copy to drift away from. For these jobs a portal, Backstage or a managed one, is a good buy, and I would not argue otherwise.
Other facts fail the test immediately, and they fail it in a specific and predictable place. The cross-repo infrastructure dependencies. Which repositories consume a shared Terraform module, via its source block. Which services are built on a base image, via a Dockerfile FROM. Which charts depend on which, via Chart.yaml. Which pipelines pull a shared template, via a .gitlab-ci.yml include. These already exist as declarations in the manifests. The catalog entry that mirrors them is a second copy of a fact the repo already states. Engineers must edit the manifest to ship. Nothing forces them to edit the catalog to match. So the two declarations diverge on the first commit after someone stops being diligent, and on a real team that is roughly immediately. I went through the mechanics of this in detail in the catalog maintenance trap, and the architectural version of the argument is in modeled graphs and parsed graphs.
The diagnostic, then, is a ratio of its own. The more of your intended value sits in the first bucket, the more Backstage is worth it. The more of it sits in the second, the lower your adoption ceiling, no matter how well you build it, because you are asking people to hand-maintain a copy of facts their commits already changed, and they will not, and the graph will be wrong exactly when it matters.
The change that proves it
Here is when it matters, made concrete, because this is the scene that sends teams looking in the first place.
A platform engineer needs to bump a base image, or change a shared Terraform module, the kind of change that fans out across dozens of repos that no single person has in their head. Maybe the person who did have it in their head is leaving in three weeks, and the dependency view in the portal was supposed to be how that knowledge survived their departure. This is the highest-stakes thing a portal's dependency graph is meant to do. Tell you what breaks before you ship.
And it is the exact moment the catalog model lets you down, because the graph is only as current as the last engineer who remembered to update YAML that nothing required them to update. So at the decision point where being wrong is most expensive, you are consulting the data you should trust least. A portal you cannot trust when the change is risky is not a safety net. It is a comfort blanket with holes you find out about during the incident. That is the worth question with the abstraction stripped off. The maintenance cost everyone complains about does not even buy you the one answer you most needed it for.
When it is genuinely worth it
So let me be precise about when the answer is yes, because it often is.
If you have a platform team with real frontend capacity, an organisation large enough that the per-developer cost amortises, a genuine need to own and extend the portal, and, most importantly, the organisational will to enforce the metadata-in-the-repo discipline that makes Spotify's catalog stay true, then Backstage is a defensible and often excellent choice. The teams in Roadie's "very happy" 70% are real. They earned it by paying the standing cost on purpose and putting the data where the work is.
And if you are small, the most honest take comes from a Backstage vendor. Roadie themselves say plainly that not every organisation needs Backstage, and that below a certain size adopting it is over-engineering. The mistake is almost never "adopted Backstage". The mistake is adopting any catalog-model system, Backstage or a commercial successor, for the second-bucket data, and then spending finite organisational willpower keeping humans in sync with facts their repositories already declare. That spend is the maintenance everyone complains about, and for that category of data it does not buy accuracy. It buys a graph that is right up to whenever someone last cared.
So, is it worth it?
After enough of these conversations I have stopped thinking of worth as a property of Backstage at all. It is a property of the match between Backstage's data model and the data you intend to put in it. For the facts humans declare on purpose, the match is good, and for the right organisation the portal earns its keep handsomely. For the cross-repo infrastructure dependencies, the match is wrong at the root, and no amount of budget, frontend talent, or vendor support fixes a model that asks people to re-declare what they already declared. You will land in the 10% for that part of the portal specifically, and you will have paid for the privilege.
If the reason you are evaluating Backstage is some version of "we need to know what breaks across our infrastructure before we change it, and we need that to still be true after the person who knows leaves", then the worth-it calculation is not close, and not because Backstage is bad. It is because that particular fact should never be maintained by hand in the first place.
That last job is the one I build for. Riftmap connects to a GitLab or GitHub organisation with one read-only token and parses the infrastructure dependency edges directly from the manifests that already declare them, across Terraform, Docker, Helm, Kubernetes, CI templates, and more. There is no catalog to maintain because there is no second copy. The graph cannot drift from the source, because the source is the input, which means it is still right at the moment you bump the base image or touch the shared module and need to know what is downstream. It is not a developer portal and it will not become one. If the value you are after is golden paths, scorecards, and ownership pages, use Backstage or a managed portal, and I mapped the honest options by job in Backstage alternatives in 2026. If the value you are after is knowing what breaks before you ship, that is a different tool, and the free tier covers 15 repos.
Top comments (0)