Independent public project review of Backstage, created by Spotify and hosted by the CNCF. The business portal and handover example below are proposed applications of its design, not a Spotify or OdooMatrix client engagement.
1. The cost of software without visible ownership
A customer portal fails and staff cannot find its owner, deployment notes, or support contact. Another team starts rebuilding a capability that already exists elsewhere. These are operating problems as much as technical ones: knowledge is scattered across repositories, chats, personal notes, and outside vendors.
Backstage’s public documentation describes an open source framework for developer portals, centered on a software catalog. Its repository identifies Spotify as the creator and the Cloud Native Computing Foundation as the project’s current host.
The business lesson is to give software a discoverable identity and accountable owner. That does not require copying Spotify’s organization or assuming every company needs a developer portal. The catalog must solve a real coordination problem and have people responsible for keeping it accurate.
2. What Backstage brings together
The public project groups several capabilities around a central portal. The software catalog records components and ownership; Software Templates support standardized project creation; TechDocs brings documentation into a docs-as-code workflow. Plugins can connect other tools into the experience.
A catalog is a map of responsibility and useful references. It does not automatically monitor every production service, repair an outage, manage an ERP implementation, or validate the truth of an ownership record. Integrations and an operating process are needed for those outcomes.
Templates can standardize a starting point, but they create ongoing obligations too. Someone must maintain dependencies, deployment patterns, and the documentation those templates generate. A catalog full of stale services can be less useful than a small, accurate register.
3. Design a portal around business-critical services
For an illustrative company with several web applications, an ERP, and outside delivery partners, begin with the systems that support orders and customer service. Agree what constitutes a service and which team is responsible for each record.
On small screens, scroll the table sideways to see every column.
| Field | Why the business needs it |
|---|---|
| Business capability | Explain what the service supports, such as orders, invoicing, or customer access. |
| Accountable team | Provide an agreed support route with a backup owner. |
| Repository and environments | Connect implementation and deployment references without storing credentials. |
| Runbook and dependencies | Explain incident actions and systems that may be affected. |
| Lifecycle and review date | Identify active, retiring, and unreviewed services. |
Start with read access appropriate to the audience. A developer portal may link to an operational dashboard, but that link should not grant broader production permissions. Keep access decisions with the connected systems and identity configuration.
4. Walk through a supplier-to-team handover
In a sample handover, an outside development partner delivers a customer portal and its order synchronization service. A useful catalog shows the responsible internal owner, source repositories, release procedure, integration dependencies, and the route for raising an incident.
Ask a team member unfamiliar with the project to find the service owner, locate the test environment, and explain the first response to a failed synchronization. That exercise checks the handover from the recipient’s perspective, rather than counting uploaded documents.
- The named owner confirms responsibility and can update the record.
- The runbook links to current procedures and distinguishes test from production.
- An employee changing teams does not leave a personal account as the only support route.
- A retired service is marked clearly and removed from new-project templates.
These are illustrative acceptance checks, not published Spotify measurements.
5. Introduce the catalog before expanding automation
Inventory a limited set of critical services and reconcile the proposed records with their owners. Establish a simple review process and make catalog updates part of a project’s handover. Importing every repository first can create a large list with little business meaning.
Once the catalog is useful, choose one repeated project type for a template. Review generated repositories, configuration, documentation, and deployment references as a team. The template should make the approved path understandable while leaving room for justified variations.
Train internal staff and outsourced contributors on ownership changes, support escalation, and documentation reviews. Assign platform maintenance as ongoing work. The portal’s value depends on operational adoption as much as its interface.
6. Measure whether people can find what they need
Track the share of critical services with a confirmed owner and current runbook, time to locate a responsible team, incomplete handovers, and time for a new contributor to reach the documented development setup. Define the exercise consistently before comparing results.
Avoid treating catalog size as success on its own. A smaller set of accurate records can support an incident more effectively than a complete-looking list no one maintains. Review outdated entries and broken references as regular operating work.
For a small organization, a maintained service register and shared runbooks may meet the need. Reuse the ownership model first; adopt a portal framework when service count, team boundaries, and integration needs make it worthwhile.
7. Frequently asked questions
Is Backstage an ERP or an infrastructure monitoring product?
It is a framework for building developer portals. Its catalog, documentation, templates, and plugins can bring references and tools together, but connected business and monitoring systems keep their own responsibilities.
Does a small business need a Backstage portal?
Not necessarily. A maintained service register and good handover documentation may be sufficient. Consider a portal when many services, teams, and tools make discovery and ownership difficult.
Can outsourced developers participate in the catalog process?
Yes, with access appropriate to their work and clear internal ownership. Include service records, runbooks, support routes, and ownership transfer in the delivery and handover requirements.