Why Backstage might not be worth it

I'm a tech lead who spent the better part of several months trying to build an Internal Developer Platform (IDP) with Backstage. This wasn't full-time work - it was hours here and there during work, plus a lot of my own free time trying to figure it out. I eventually scrapped it and built my own solution in a matter of days. Here's why you might want to skip Backstage too.

The Backstage Promise

To be fair, Backstage doesn't promise to be a done-for-you IDP. It's a framework for building an IDP, with a rich plugin ecosystem to help you get started. Need to display GitHub data? There's a plugin. SonarQube metrics? Plugin. Grafana dashboards? Plugin. The idea is that you can use these as building blocks for your own custom developer portal.

And honestly? That sounds reasonable.

The Reality: Plugins Are Just Frontend Displays

When I started building our IDP, I found plugins for most of what I needed: GitHub, SonarQube, Grafana, Keycloak, and even MKDocs for documentation. Many of them worked fine for their basic purpose - displaying data.

But here's where things fell apart: I wanted to build something more than just a dashboard.

I wanted to add gamification to our IDP. I wanted to rank projects and repositories by:

• Documentation quality and completeness
• Test coverage
• Time to merge PRs
• Other metrics that would encourage good engineering practices

This seemed like exactly the kind of thing an IDP should enable, right?

Except it doesn't work with Backstage's plugin architecture. Here's why: none of the plugins actually save data on the backend.

They're all ephemeral frontend components that fetch data, display it, and forget it. There's no persistence layer. No way to track trends over time. No way to aggregate data across plugins. No way to build features that depend on historical data or cross-service analysis.

Want to track how a team's test coverage has improved over the last quarter? Can't do it - the SonarQube plugin just shows you current metrics. Want to correlate documentation completeness with merge times? Can't do it - each plugin operates in isolation with no shared data model.

The Fundamental Architecture Problem

This isn't just about missing features in specific plugins. It's a fundamental limitation of how Backstage plugins work. They're designed as isolated frontend components, not as integrated backend services.

To build the features I actually wanted, I would need to:

1. Build my own backend services anyway
2. Store and manage data myself anyway
3. Create my own APIs anyway
4. Then somehow integrate all of this with Backstage's architecture

At that point, what is Backstage actually giving me? A React component framework? I already know React. A routing system? Every web framework has that.

I Loved the Idea of Backstage (But Not Backstage Itself)

Here's something I realized only in hindsight: I was conflating two different things.

I loved the idea of an Internal Developer Platform. A single place where developers could:

• Discover services and their owners
• See documentation, metrics, and dashboards
• Track code quality and engineering practices
• Spin up new projects from templates
• Get insights into team performance

That vision is compelling! It's a good idea! But here's the thing: that's the idea of an IDP, not the idea of Backstage specifically.

When you read about Backstage, see the demos, and browse the plugin marketplace, it's easy to fall in love with what an IDP could be. Backstage does an excellent job of evangelizing the concept. But the vision of "what an IDP should do" is separate from "whether Backstage is the right way to build it."

I think a lot of people (myself included) get excited about Backstage because they're actually getting excited about finally building an IDP. Then they assume Backstage is the inevitable choice because it's the most well-known option.

But you can build an IDP without Backstage. In fact, depending on your needs, you probably should.

The Hidden Costs of "Free" Plugins

At this point, I faced a choice: dig deeper into Backstage's architecture, learn its plugin development patterns, and build custom solutions within its constraints, or start fresh.

I chose to start fresh. And here's the kicker: I rebuilt what I needed in days, not months.

Now, to be fair, I had context from my time with Backstage. I understood what I was trying to build. But even accounting for that, the difference was stark. With tools I already knew (in my case, a modern web framework I was comfortable with), I could:

• Build exactly what I needed, no more, no less
• Iterate quickly without fighting framework constraints
• Use patterns my team already understood
• Deploy and maintain it without a massive complexity overhead

The Sunk Cost Trap

Here's the thing about Backstage: it has a steep learning curve. You need to understand React, TypeScript, its specific architectural patterns, its plugin system, its backend architecture, and more. For a full-time platform team, maybe that investment makes sense.

But I'm not a full-time platform engineer. I'm a tech lead building this "on the side" alongside my other responsibilities. And I suspect that describes a lot of people trying to build IDPs.

When you've already invested weeks or months learning Backstage, it's psychologically hard to walk away. You think, "I just need to understand it a bit better, then it'll click." But that's the sunk cost fallacy talking.

When You Might Actually Need Backstage

Look, I'm not saying Backstage is worthless for everyone. There are scenarios where it might make sense:

• You have a dedicated platform team with time to invest
• Your requirements closely match what Backstage's plugins provide out-of-the-box
• You're a large enterprise that values standardization on a known framework over speed
• Your team already has deep Backstage expertise

But for most teams, especially smaller ones or those just starting their IDP journey, I think you're better off building something simpler.

What I Built Instead

Instead of Backstage, I built a lightweight web application using tools my team already knew. Here's what it does:

• Service catalog connected to our GitHub organization
• Integrations with SonarQube, Grafana, and our documentation (MKDocs)
• Backend persistence that stores metrics over time
• Gamification system that ranks projects by:
  • Documentation completeness
  • Test coverage
  • Average time to merge PRs
  • Other custom metrics we care about
• Trend tracking so we can see improvement over time
• Custom authentication with Keycloak that works exactly how we need it

The key difference? Because I built the backend myself, I could actually do things with the data. I could store it, analyze it, correlate it across different services, and build features on top of it.

Could it do more? Sure. But it does exactly what we need, and my team can maintain and extend it without becoming Backstage experts.

The Core Question

The real question isn't "Is Backstage powerful?" It is. The question is: "Is Backstage solving enough problems to justify its complexity?"

For us, the answer was no. You might find a different answer, but I encourage you to honestly evaluate:

1. How much of Backstage's functionality do you actually need?
2. How much customization will you need to do anyway?
3. Does your team have the time and expertise to invest in this framework?
4. Could you build what you need with tools you already know?

If you're spending more time fighting the framework than building features, that's a sign.

The Bottom Line

Backstage is impressive technology. But impressive doesn't always mean practical. Sometimes the best solution is the one you can actually ship, maintain, and iterate on without requiring a PhD in Backstage Architecture.

For me, that meant walking away from months of investment and starting fresh. It was the right call. It might be for you too.