On this page
Backstage is everywhere.
Reported usage now sits at more than 3,400 organisations and more than two million developers outside Spotify. Roughly nine in ten developer portal projects use it. It is the default answer to the question “how do we build an internal developer portal?”, and the default answer is, in most cases, correct.
The problem is that the question being asked has changed. Engineering leaders adopting Backstage in 2026 are not asking how to build a portal. They are asking how to build a platform, and they are buying Backstage because they have been told it is the answer.
It is not the answer. It is a part of the answer. Confusing the two is producing the most expensive platform engineering mistake of this cycle.
What Backstage Actually Is
Backstage is a developer portal framework. At its core, it provides four things:
- A service catalogue that lists the components, systems, and APIs that exist in the organisation, with metadata about who owns them.
- Software templates that scaffold new services from defined starting points.
- Technical documentation in a unified location.
- A plugin system that lets engineering teams surface other tools and data through the portal.
These are real capabilities. A well-implemented service catalogue alone produces meaningful value in a large engineering organisation, because the alternative is tribal knowledge about what exists and who owns it.
But notice what Backstage does not provide. It does not deploy your services. It does not manage your environments. It does not enforce your standards. It does not run your infrastructure. It does not provision your databases. It does not handle your secrets. It does not produce your observability.
What it does is present these capabilities, where they exist, through a unified interface. If the capabilities exist underneath, Backstage makes them more useful. If they do not exist, Backstage cannot conjure them into existence.
Backstage is a portal. The platform is what sits behind the portal.
What a Platform Actually Is
A platform, in the sense engineering leaders mean when they talk about platform engineering, is a set of capabilities that let application teams ship software without thinking about the underlying infrastructure.
A working platform has:
- Golden paths. A standard, opinionated way to deploy a service, with the infrastructure provisioning and configuration handled by the platform.
- Self-service workflows for the operations developers most commonly need: creating a service, provisioning an environment, rotating a secret, requesting capacity.
- Consistent observability that works the same way for every service on the platform.
- Enforced standards for security, networking, and resource use, applied through automation rather than through approval queues.
- A clear ownership model that lets the platform team operate the shared substrate without owning every team’s application problems.
The relationship between Backstage and a platform is the relationship between a steering wheel and a car. The steering wheel makes the car easier to use. The steering wheel is not the car. If you do not have a car, the steering wheel is not useful by itself.
This is not a controversial claim inside the platform engineering community. It is, however, frequently lost in the conversation around Backstage adoption.
How the Confusion Plays Out
The pattern is consistent across organisations adopting Backstage as a platform rather than as a portal.
An engineering leader is asked to invest in platform engineering. They look for a defensible technology choice. Backstage has the brand and the adoption numbers, so they choose it. A team is assembled to roll it out. Months of effort go into setting it up, configuring plugins, and producing a service catalogue.
Six months in, the team discovers that Backstage, configured, is not producing self-service. Developers can see a catalogue of services. They can use software templates to scaffold new ones. But they still cannot deploy without involving the platform team, still cannot provision environments without filing a ticket, still cannot rotate a secret without asking somebody.
The conclusion is usually that “we need more Backstage plugins.” This is not the right conclusion. The right conclusion is that the underlying platform that Backstage is supposed to surface does not yet exist.
The Backstage project then becomes a long-running engineering effort to maintain a tool that the organisation cannot fully use. Plugin upgrades break things. The catalogue requires constant curation. New use cases each require a plugin development project. The team’s time is consumed by the portal, while the platform underneath remains inconsistent.
This is the trap. The portal becomes the project, and the platform never gets built.
The “We Have Backstage” Trap
Engineering leaders should be careful of organisations - their own or others - that present Backstage adoption as evidence of platform engineering maturity.
It is not. Backstage adoption is evidence of portal investment. Whether the underlying platform actually exists is a separate question, and one that the existence of Backstage does not answer.
The diagnostic questions are straightforward:
- Can a developer deploy a new service to production end-to-end, without involving the platform team, using a path the platform supports? If yes, the platform is real. If no, Backstage is a catalogue of things you cannot yet do.
- Are environments self-service? Are secrets self-service? Is observability automatic for every service? If these are tickets, the platform is the ticketing system.
- Does the Backstage catalogue represent capabilities the platform actually provides, or does it represent links to documentation about how to do things manually?
A Backstage instance that surfaces real self-service capabilities is a developer portal for a working platform. That is the model that produces the value the framework was designed for.
A Backstage instance that surfaces documentation links and ticket forms is a sophisticated SharePoint replacement. That is the model that produces six months of work and no operational change.
When Backstage Is the Right Choice
Backstage is the right choice in a recognisable set of conditions.
The organisation has enough engineers - typically several hundred or more - that a portal layer is genuinely useful. Below that scale, the maintenance cost of Backstage tends to exceed the productivity gain from having a unified portal.
The underlying platform already provides, or is on a credible path to provide, the self-service capabilities the portal will surface. Without this, Backstage becomes a catalogue of manual processes.
There is engineering capacity to maintain a Backstage instance long-term. The plugin ecosystem is rich but fragile; breaking changes happen, plugins require ongoing maintenance, and Backstage as a piece of software needs continuous investment to stay current. Organisations that cannot commit to this should consider lighter-weight alternatives.
The organisation values the open-source, extensible nature of Backstage enough to justify the cost over a commercial alternative. For some organisations - particularly those that need to integrate Backstage deeply with internal systems - this is genuinely the right trade. For others, a commercial portal is faster, cheaper, and more sustainable.
These conditions describe a real population of organisations. They do not describe most organisations adopting Backstage in 2026.
What to Do Instead, Sometimes
For organisations that do not meet those conditions, the alternatives are usually one of:
- Build the platform without a portal first. Make sure the underlying golden paths, self-service workflows, and ownership models exist and work. Add a portal later, when there is genuinely something to surface. The portal is the last layer, not the first.
- Use a commercial developer portal. Tools in this category have invested heavily in the user-facing capabilities of a portal, and trade away some of Backstage’s extensibility for a shorter time to value. For organisations that do not have the engineering capacity to maintain Backstage, this is often the right trade.
- Skip the portal entirely. For organisations under fifty engineers, a well-documented set of golden paths, a clear ownership model, and a Slack channel for help often outperforms a portal investment of any kind.
The decision is not whether to have a portal. It is whether the cost of building and maintaining one matches the value the organisation will get from having one.
The Takeaway
Backstage is excellent at what it is for. It is the most credible open-source developer portal framework in the industry, and for organisations that need a developer portal, it is the default choice for good reasons.
The mistake is treating Backstage as the platform itself rather than as a portal on top of one. This produces a predictable failure mode: significant engineering investment in a tool that surfaces capabilities the organisation does not yet have, and a corresponding lack of investment in the platform underneath that would actually produce self-service.
Before adopting Backstage, the question to answer is not “should we use Backstage?”. The question is “do we have a platform yet?”. If the answer is yes, Backstage is probably the right portal for it. If the answer is no, Backstage is the wrong investment to make first.
If you are about to make a Backstage decision and you are not sure whether the platform underneath is ready to support it, we can help you work that out.