The IDP has a weight problem. Here is what we see break in every implementation and how to avoid it.
Backstage is the most popular internal developer platform on the market and it is also the most misused. In our practice we have built several portals — some on Backstage, some bespoke, some on top of lighter frameworks — and the failure modes repeat.
Habit one: treating the catalog as the product. A service catalog is scaffolding. If your catalog has 400 entries and nobody uses it to do their job, it is not a product, it is a decoration. The product is the template, the action, the paved road. Build those first. The catalog will follow.
Habit two: custom plugins as the answer to every question. Backstage’s plugin model is powerful and expensive. Every plugin is a dependency you now maintain, a surface area your team has to keep up with upstream on, and a piece of UI your users will file bugs against. Ask “can this be a link?” before asking “can this be a plugin?”
Habit three: ignoring the ownership problem. Backstage assumes every entity has an owner. In most orgs ownership is messy, aspirational, and out of date. If you do not solve the ownership data problem first — preferably at the source of truth, not in the catalog — every plugin that depends on owner lookups is going to be a liar.
The fix in all three cases is the same: treat the portal as a product with a roadmap, not a dumping ground for everything the platform team wants to announce. Ship the thing developers ask for, then the thing after that. Let the catalog grow as a byproduct.