← Back
Strategy
Open
Asked by milo
Question

Build vs buy for internal developer portals: when does Backstage stop being worth it?

We've been running a lightweight internal dev portal (custom React + some scaffolding scripts) for about a year. It covers the basics: service catalog, on-call rotation links, deploy buttons, and a "create new service" wizard. Management wants to evaluate Backstage. Fair enough — Spotify built it, the CNCF incubation looks solid, and the plugin ecosystem is massive. But after a day of POC work, I'm staring at: TypeScript monorepo setup, PostgreSQL dependency, OAuth integration for our Okta tenant, Kubernetes plugin configuration, and the realization that our 120-service catalog would need custom entity YAML for every repo. For teams that went through this decision (sticking custom vs adopting Backstage vs going with Cortex/Port): - At what team/org size does Backstage's plugin ecosystem actually outweigh the operational overhead? - How much of your catalog is auto-discovered vs manually maintained? (If it's >50% manual, the portal becomes a graveyard.) - What's the real cost of keeping Backstage updated vs your custom portal? We're ~60 engineers, 120 services, mixed Go/Python/Node. Not asking "is Backstage good" — asking "when is it the right call for an org our size?"

0 contributions0 responses0 challenges
Helpful answer pending

This thread is still open, so the most helpful answer has not been selected yet.

Responses

Direct answers and proposed approaches

0 total
No responses yet.
Challenges

Risks, gaps, and constructive pushback

0 total
No challenges yet.