5 Clear Signs that you've Outgrown Backstage
)
Open Source Doesn't Mean Free
)
January 14, 2026
Backstage is awesome. It solves a really challenging problem - how do you empower developers to "get things done" on their own with minimal overhead. The software is open source (free) and fully customizable to your use-cases. Organizations both small and large have adopted Backstage with success; however, there's an elephant in the room: Backstage doesn't scale to how enterprises operate. Most large organizations eventually "outgrow" Backstage. Here's 5 clear signs that this is happening to you:
#1 - Operating your "free" platform costs more than paying for SaaS
For large enterprises, operating Backstage generally requires the following teams:
- Cloud Infrastructure - your cloud infrastructure team need to allocate resources, configure logging, monitoring, alerting, storage
- DevOps / Platform Engineering - your DevOps / Platform Engineering teams must create pipelines to build your Backstage images, deploy to cloud infrastructure, execute rollbacks, execute new deployments, design and execute tests, and configure integrations
- Support Team - your Support team needs to lean how Backstage works, understand how it is deployed, and learn how to debug non-Backstage issues (e.g., an engineer might try to run a self-service workflow, it fails, and they create a support ticket)
At first glance, every enterprise organization already has these teams. In practice, enterprises need to train existing staff and hire net new to ensure the skills are present. In my previous role as a DevOps consultant, I typically saw enterprises hire a dedicated team of 3-5 engineers to manage the environment, plus a larger global team to provide specialized support given the complexity of the platform. This often added > $3.0m in overhead to run "free" software when buying an enterprise SaaS product would cost substantially less.
#2 - Service Catalog maintenance is a drag on developer productivity
One of Backstage's most important features is the service catalog. It allows you to create a unique map of your services and provide automations to support them. However, as applications mature, they change. Those changes need to be represented in your service catalog or it becomes stale.
The issue is that enterprise organizations often have hundreds or even thousands of software applications. Keeping that many applications up to date in Backstage's service catalog is incredibly expensive. Software engineers need to spend a few hours each week to keep the service catalog up-to-date, which decreases productivity and adds up financially for larger institutions. What generally happens is the service catalog becomes out of date and remains that way.
#3 - Your Backstage portal simply points to documentation from other systems
Backstage isn't actually a developer portal - it's a framework that makes it easier to build a customizable developer portal for your organization. That's one of the best selling points of Backstage - you can customize it however you'd like. However, unless your organization hires frontend software engineers and integration engineers to actually implement the custom functionality that you want, Backstage often ends up being a portal that links out to other documentation platforms.
I can't tell you how many times I've worked with customers that had beautiful Backstage portals, organized nicely with color-coded cards representing their applications and automations, yet clicking on the buttons opened up a Confluence page.
#4 - You spend more time building your portal than actually using it
Speaking of building your portal, it takes time. You need to understand how it works, deploy the platform, and update it for security fixes. Then you need to actually build all of the custom functionality to make it "yours." This takes high-skill software engineers, and they really need to be dedicated to the project to support your portal over time. You also need a few dedicated DevOps Engineers to create and maintain all the automations that your users consume as part of your Backstage portal.
Therein lies the issue - you end up paying the customization tax, to the tune of thousands of hours and millions of dollars per year to maintain your "free" developer portal. At some point, the financials stop making sense and your organization would actually save money purchasing licenses for an existing SaaS developer platform.
#5 - You want a development portal that is AI-native
Backstage doesn't have any native AI functionality. For organizations that are trying to improve productivity via AI adoption, using Backstage is actually a step backwards. The productivity gains from AI chat alone are overblown, but applications that integrate AI into their core functionality provide incredibly useful features to help people get their jobs done.
If your goal as an organization is to better leverage AI as part of your software, DevOps, and Platform Engineering process, Backstage isn't going to help you unless you expend serious engineering effort to create plugins that fit your use-case. Over time, this increases your total maintenance costs. For some organizations, that cost exceeds $9m/year, when they can spend less than a quarter of that on existing SaaS platforms that do very similar things.
What's next? Take action.
Ultimately, large enterprises struggle to adopt Backstage because it is very expensive to maintain, sometimes actually decreases productivity, and is lagging behind AI-powered platforms. The question becomes: "do we continue maintaining our expensive platform, or do we look to other more modern solutions to get the same things done more cheaply?"
If your goal is to improve developer productivity and DevEx while cutting costs, now is the time to act, or at least start searching.
C
CodeCargo Team
The CodeCargo team writes about GitHub workflow automation, developer productivity, and DevOps best practices.