The True Cost of Self-Hosting Backstage: A Build vs. Buy Analysis for Engineering Leaders

Your platform team is fielding 30 Slack messages a day. "Who owns the payment service?" "How do I get an S3 bucket?" "Does virus scanning exist in our environment?"

Someone suggests Backstage. You look at the README, see it's open source, and think you'll just spin it up.

Six months later, you've burned through your platform team's roadmap, your catalog is half-populated, and developers are still opening JIRA tickets for everything.

At my previous company, we built an internal developer portal from scratch. The bill ran into the millions. That experience taught me that every engineering organization over 100 people eventually needs this infrastructure. But it also showed me how expensive it is to build and maintain. Even with AI coding agents to help with development, there’s a thousand small decisions to make about business logic.

Now, as CEO of Roadie, I talk to engineering leaders every week who are making this build vs. buy decision. Most underestimate what self-hosting Backstage actually costs. Not just in dollars, but in team capacity and time to value.

Here's what the decision really looks like.

The Problem You're Actually Solving

The developer portal problem starts small. You're managing 50 services across 30 teams. Someone asks which services depend on the auth API. You don't have a good answer.

Another team needs virus scanning. You think it exists somewhere, but you're not sure.

So you make a spreadsheet. Service name, owner, what it does. Problem solved.

This works for about three weeks. Then nobody updates the spreadsheet. It's out of date. People stop trusting it.

This is the discoverability problem. At 10 engineers, you just shout across the office. At 100+ engineers, that breaks down completely. You need a software catalog that actually stays current.

But discoverability is just the first problem. You also hit:

The self-service bottleneck: A mobile developer needs an S3 bucket. They don't know Terraform. They open a JIRA ticket. Your platform team gets to it in two weeks. The developer either waits or bypasses your platform entirely and creates shadow IT.

The governance gap: Your security team needs to verify every service has proper on-call setup. Your compliance team wants to check access controls. You need automated checks against your entire software catalog, not manual audits.

These three problems drive every developer portal evaluation. The question isn't whether you need a solution. The question is whether you build it or buy it.

What Backstage Actually Gives You

Backstage is not a developer portal. It's a framework for building one.

This distinction matters. When Spotify open sourced Backstage in 2020, they released their toolkit for building developer portals, not a turnkey product. You get a collection of TypeScript libraries and React components. You have to assemble them into something useful.

This creates immediate friction for most platform teams:

You need TypeScript expertise. Most platform teams work in Go, Python, and YAML. Web development is a different skillset than infrastructure engineering. You either hire TypeScript developers or retrain your existing team.

You're building, not configuring. Out of the box, Backstage gives you basic catalog functionality. It doesn't give you role-based access control. It doesn't give you production-grade search (it runs on Postgres full-text search). It doesn't give you most enterprise features. You build those.

You're maintaining a web application. Backstage releases a new version every couple of weeks. Each upgrade can break your plugins. Each new integration requires custom TypeScript code. This is ongoing work, not a one-time project.

The Real Cost: Team Capacity

When we surveyed the Backstage community this year, organizations that reported being happy with their self-hosted deployment had at least three dedicated engineers. Some teams were as large as 12 people.

Let me translate that into budget terms. Three mid-level engineers cost around $450,000 per year in salary, benefits, and overhead. That's the minimum for a successful deployment.

But the real cost is what those engineers aren't doing.

Time to production: 6-12 months. You're not launching next sprint. You're building the catalog model, integrating CI/CD tools, setting up authentication, configuring plugins, and training teams. The organizations we talk to consistently report 6-12 months before they had something teams would actually use.

Opportunity cost. Those three engineers aren't improving your CI/CD pipeline. They're not hardening security. They're not building platform capabilities that differentiate your business. They're maintaining a developer portal.

Missing features you have to build. Need RBAC so your security services aren't visible to everyone? You're building that. Want better search? You're integrating Elasticsearch. Want API documentation? You're configuring and maintaining that integration.

The actual costs break down into several categories:

• 3 engineers minimum at $150k loaded cost each = $450,000/year
• 9 months to production at 60% team efficiency = ~$200,000 in delayed value
• Ongoing maintenance and feature development
• TypeScript training or new hires

First year total exceeds $800,000. Every year after that is still $450,000 minimum, assuming no team growth.

And you still haven't built all the features you need.

When Building Makes Sense

Self-hosting Backstage gives you something valuable: control.

If you have unique requirements that no vendor can handle, being able to modify every line of code matters. If you're integrating with complex legacy systems, having full access to the source code can be critical.

You also get the Backstage ecosystem. The community is active. New plugins appear regularly. If you need an integration with a specific tool, someone in the community might have already built it.

Some engineering leaders prefer ownership for critical infrastructure. They don't want vendor dependencies. They want the source code running in their environment.

These are legitimate reasons to self-host. But they need to justify the cost.

Build if:

• You have genuinely unique requirements no vendor can handle
• You already have a team with TypeScript expertise who wants to own this
• You're large enough (500+ engineers) that control benefits outweigh costs
• You have specific security requirements that mandate on-premises deployment
• Your platform team has capacity to spare

Don't build if:

• Your platform team is already stretched thin
• You want to launch in weeks, not months
• You need enterprise features without building them
• You'd rather focus engineering resources on your actual platform

The key question: What do you want your platform team working on? If the answer is "building platform capabilities that make our engineering organization more effective," you probably shouldn't be maintaining a developer portal.

The Managed Alternative

When we built Roadie, the goal was straightforward: give you Backstage without the team overhead.

Here's what that means:

Day one deployment. You connect your GitHub organization. Your services start populating. No six-month buildout. No TypeScript work. You're configuring, not coding.

Enterprise features included. RBAC, production-grade search, authentication integrations. The pieces you'd have to build yourself are already there, built from feedback across hundreds of deployments.

Automatic upgrades. When Backstage releases a new version, we test it, validate it, and roll it out. You don't manage the upgrade cycle. You don't deal with breaking changes.

No TypeScript team required. You use a web UI to configure Backstage. Your platform team stays focused on platform work.

The financial calculation is simple. Managed Backstage costs a fraction of a three-engineer team. But the more important comparison is what your platform team accomplishes.

Would you rather have three engineers maintaining Backstage, or three engineers improving your CI/CD pipeline and building platform capabilities?

The Hybrid Approach

This is Roadie's actual positioning: the hybrid model.

Proprietary developer portals lock you into their data model. If they don't support your integration, you're stuck. If they sunset a feature, you adapt. You have no control.

Self-hosted Backstage gives you control but requires a dedicated team and significant TypeScript expertise.

Managed Backstage sits in the middle:

• The flexibility of Backstage's open source ecosystem
• Day-one usability and enterprise features
• No team overhead, no TypeScript requirement, no year-long buildout

You're not locked into a proprietary platform. If you decide you want to self-host later, you can. The catalog format is standard Backstage. Your plugins are standard Backstage.

But you also don't need to staff a team just to keep the portal running.

The Path Few Consider

Most engineering leaders frame this as "self-host Backstage vs. buy a proprietary portal." But there's a third option: start managed, migrate to self-hosted later if needed.

You can validate that Backstage solves your problems without burning six months and half your platform team's capacity. Get your catalog populated. Get teams using it. Prove the value.

Then, if you decide you need more control, migrate to self-hosted. The data model is identical. The plugins are the same. You're not locked in.

Several of our customers took exactly this path in reverse. They self-hosted Backstage, realized it was consuming their platform team, and migrated to Roadie to free up those engineers for higher-value work.

Making the Decision

Here's the framework I use when talking to engineering leaders:

Start with team capacity. Can your platform team absorb a year-long project plus ongoing maintenance? If not, you're not really choosing to build. You're choosing to delay.

Calculate opportunity cost. What else could three engineers accomplish in a year? New CI/CD capabilities? Better security tooling? Improved developer experience? Is maintaining a developer portal more valuable than those alternatives?

Consider your timeline. Do you need this solved in weeks or months? If you need it fast, you're buying. If you have a year to spare, you might build.

Evaluate your requirements. Do you have genuinely unique needs, or do you just need a software catalog with good search, RBAC, and common integrations? Most organizations overestimate how unique their requirements actually are.

Think about your team's preferences. Does your platform team want to work on TypeScript and React components, or do they want to work on platform capabilities? Forcing engineers to maintain infrastructure they don't want to maintain leads to burnout and turnover.

The honest answer for most organizations under 500 engineers is that building doesn't make financial sense. You can get Backstage with all the ecosystem benefits for a fraction of the cost, with immediate deployment, and without tying up your platform team.

What This Really Comes Down To

The question isn't whether you need a developer portal. If you're managing 50+ services across 30+ teams, you probably do.

The question is whether building and maintaining that portal is the best use of your platform engineering resources.

For most engineering leaders, the answer is no. Your platform team should be improving your platform, not maintaining a web application.

That's why Roadie exists. You get Backstage without the team overhead. You get the open source ecosystem without the TypeScript requirement. You get day-one deployment without the year-long buildout.

And your platform team gets to focus on the work that actually differentiates your business.

The build vs. buy decision isn't really about cost. It's about what you want your team working on. Choose accordingly.

Next Steps

If you're evaluating Backstage for your organization, here are concrete next steps to help you move forward:

Explore Backstage capabilities: Review our comprehensive guide to Backstage to understand what's possible with the platform and how organizations are using it today.

See how others decided: Read case studies from engineering teams who've made the build vs. buy decision. Learn from Celonis's experience migrating from self-hosted to managed and how Contentful maintained velocity through hypergrowth.

Understand the full cost picture: Dive deeper into the complete cost breakdown of self-hosting Backstage to validate your budget estimates.

Try it yourself: Request a demo to see how managed Backstage works, or start a free trial to experience Roadie firsthand and get your catalog populated in hours, not months.

Compare your options: Review Backstage alternatives and approaches to ensure you're making an informed decision about your developer portal strategy.