From a Spreadsheet and a $2M Bill: Why We Built Roadie

I was an infrastructure product manager at a large enterprise SaaS company when I first ran into the problem that would eventually lead to Roadie. We were building out what was essentially a private AWS inside the company, virtualization platforms, logging systems, monitoring infrastructure, the works. It was going well. Maybe too well.

Teams kept deploying more stuff onto our platform. The security team had services running. There was a virus scanning team. Dozens of other teams I didn't even know existed were all running their software on our infrastructure. At around 50 services, people started asking questions we couldn't answer.

Who owns this thing? If it goes down at 2am, who do I call? Is it secure? How many resources should we allocate to it?

The Spreadsheet Solution

To help answer these questions, we started with what everyone starts with: a spreadsheet. One column for service names, another for owners, another for what it does.

It lasted about three weeks before it became useless. Nobody updated it. The information got stale. We had services running in production that weren't in the spreadsheet and entries for services that had been decommissioned months ago.

So we did what any self-respecting infrastructure team would do, we built a custom solution.

The $2 Million Developer Portal

We built a UI that could list all the services, show where they were running, and let people create new services with the click of a button. You'd fill out a form, and you'd get a repo with code that would run perfectly on our platform. You could configure your networking rules without going through ten Slack messages trying to find the right person. It was genuinely useful.

When I look back at the team size and time involved, I estimate we spent about $2 million USD building that thing from scratch. That isn't an exaggeration; it’s standard math when you factor in the salaries of the engineers, product managers, and designers required to build and maintain an internal product over several years.

And here's the thing: when I talked to people at other companies, they'd all built some version of the same solution to the same problem.

The Turning Point for Developer Tools

Fast forward to 2020. I'm leaving that role, and I can't stop thinking about this problem. Companies are clearly willing to spend millions solving it.

Around the same time, Spotify open-sourced Backstage, their internal developer portal that they'd been using since 2016. Suddenly, there were two approaches:

• Proprietary solutions like Cortex and OpsLevel were building closed-source developer portals and selling them as SaaS products. Quick to set up, but you're locked into their data model and their way of doing things.
• Open-source Backstage gave you maximum flexibility. You could customize everything. But it came with a catch.

The Hidden Cost of "Free"

Here's what people don't realize about Backstage until they're deep into implementation: it's not a developer portal. It's a framework for building developer portals. It's TypeScript libraries that you use to construct your own solution.

That's a problem for platform teams because most of them don't know TypeScript. They know Go and YAML and infrastructure-as-code. Not React and frontend frameworks.

When we surveyed the Backstage community, we found something interesting: people who reported being happy with their self-hosted Backstage deployment had at least three engineers dedicated to it full-time. Some companies had teams of 12 people just working on Backstage.

Think about that. You're trying to solve the developer productivity problem, and you need to staff an entire team to maintain your solution. That's not solving the problem, that's just moving it around.

And keep in mind, there are features Backstage doesn't give you out of the box. Role-based access control? Build it yourself. Better search than Postgres full-text? Run and maintain your own Elasticsearch cluster.

It takes about a year to get a self-hosted Backstage instance into production. A year and a team of five people. Or you could go with a proprietary solution and be live in weeks, but give up all the flexibility and customization that made Backstage so attractive in the first place.

The Best of Both Worlds

We built Roadie to give people the power of Backstage's open-source ecosystem, all those plugins, the community contributions, and the flexibility, without requiring them to staff a team around it.

When you use Roadie, you get access to the hundreds of open-source plugins that the Backstage community maintains. Every time someone contributes an improvement to the Backstage core, you get it automatically. You're part of this massive ecosystem that's constantly getting better.

But you don't need a team of TypeScript engineers. You don't need to spend six months setting it up. You log in on day one and start using it.

We handle all the infrastructure, all the upgrades, all the features that Backstage doesn't include by default. We've added role-based access control, better search, and scorecards for tracking standards.

Who Comes to Roadie and What Problems We Solve

Here's what we see when companies come to us. They're usually in one of three situations:

They already have Backstage. Someone got excited about it, stood up an instance, and now they're realizing it's eating up way more engineering time than they expected. They want to flip it to Roadie without starting over.

They want Backstage specifically. They love the open-source ecosystem and the flexibility, but they don't have the bandwidth to build and maintain it themselves. They're doing the build-versus-buy calculation and realizing Roadie is cheaper than five full-time engineers.

They just want a developer portal. They don't particularly care if it's Backstage or something else. They have the discoverability problem—too many services, nobody knows who owns what—and they need to solve it.

For the first two groups, the decision is easy. For the third group, it comes down to whether they value flexibility and avoiding vendor lock-in. If they do, Backstage through Roadie makes sense. If they want something more opinionated and are okay with proprietary data models, other solutions might work.

These companies are trying to solve three main problems:

• Discoverability. This is the main complaint we see, and the same problem we had when I frist worked on developer portals. "We have too much stuff and nobody knows what any of it is." This extends to centralizing documentation, mapping service dependencies, cataloging API specs. It all falls under the umbrella of making it possible to find things.
• Self-service automation. Platform teams want developers to be able to get things done without opening JIRA tickets and waiting days. Need to create a new service? There should be a button for that. Need an S3 bucket? Fill out a form that generates a Terraform pull request instead of waiting for someone to do it manually. Our software templates feature handles this.
• Governance and standards. Leadership wants to know: is our software secure? Is it reliable? Are teams following our best practices? They want automated checks—is this service properly configured in our incident management tool? Does it have someone on-call? Are there critical security vulnerabilities we haven't addressed? Tech Insights makes this possible.

A developer portal doesn't magically solve these problems. But it gives you a place to tackle them systematically instead of through a patchwork of spreadsheets, Slack messages, and tribal knowledge.

What No Tool Can Fix

The biggest mistake I see companies make is thinking this is just a technical problem. They'll come to me and say "We want DORA metrics in our portal" and I'll ask "What's a deployment in your organization?" and then we discover that half their teams deploy through ArgoCD, some use Netlify, and others have their own custom pipeline.

You can't measure deployment frequency across your organization until you agree on what a deployment is. No tool can solve that for you, not Backstage, not Roadie, not anyone. That's an organizational alignment problem disguised as a technical one.

The same thing happens with service catalogs. "Show me all our services" sounds simple until someone asks "What's a service?" and three engineering managers give you three different answers.

Developer portals give you a forcing function to solve these problems and a place to encode the answers once you've figured them out.

Where Roadie's Headed

Two things are taking up most of our roadmap energy right now.

AI Integration

When you think about the questions people want answered, "Who's the engineering manager for the virus scanning service?" or "Which services depend on our authentication API?", they're perfect for conversational interfaces. You should be able to type that into a chat and get an answer. We're building that.

Automated Ingestion

This is less sexy but maybe more important. Right now, getting data into Backstage is too manual. You have to go to each team and say "put your stuff in the catalog" and that doesn't scale. We need to automatically discover and ingest services, infrastructure, and dependencies. We're making Backstage better at this than the proprietary competitors, which is crucial for wider adoption.

The Hybrid Approach

Here's how I explain Roadie to people: self-hosted Backstage sucks because you need a team of five engineers. Proprietary developer portals suck because you're locked into their data model and limited customization.

Roadie gives you the best of both. You get the massive open-source ecosystem that's constantly improving through community contributions. But you don't need to staff a team around it. You don't need to spend a year bringing it into production.

We built Roadie because we lived through building it from scratch. We know exactly how much it costs and how long it takes. And we knew there had to be a better way.

Request a demo or start a free trial to see how it works for yourself. You can also check out this case study to see how Celonis switched from self-hosted Backstage to Roadie and the results they achieved.