Backstage.

Where Backstage fits on a long engagement.

The problem Backstage addresses is real in any organisation past a certain size: nobody can answer who owns a service, where its documentation is, or what it depends on. A catalogue with enforced ownership metadata makes those answerable, which matters most during an incident.

It is a framework rather than a product, and that distinction is where adoptions fail. Running Backstage means running an application — deploying it, upgrading it, writing plugins, and keeping the catalogue accurate. A portal whose data is six months stale is worse than no portal, because people trust it briefly and then stop.

What an assigned team does with Backstage.

Catalogue accuracy is the entire value, and it decays by default. Services get created, ownership changes, teams reorganise, and unless registration is part of how a service is created, the catalogue drifts immediately.

Making it self-maintaining through scaffolding rather than policing it manually is the design decision that determines whether it survives. That kind of long-horizon platform work is assigned as a committed monthly capacity.

What we use Backstage for.

• Ownership answerable during an incident Who owns a service, available without asking three people at 3am.
• New services correct from creation Scaffolding templates that register the service and set up its baseline automatically.
• Documentation beside the code Docs-as-code surfaced in the portal, so they are updated in the same pull request.

How Backstage capacity is assigned.

Developer portal work is assigned under devops managed services, with catalogue accuracy designed in rather than maintained by reminder.