Platform engineering: build a platform developers choose to use

An internal platform creates value only when teams use it to deliver and operate software. Installing a portal, adding a catalogue and calling the result an IDP does not achieve that by itself.

The CNCF Platforms White Paper describes a platform as curated capabilities and experiences for internal customers. A platform team is therefore building a product. It has to understand users, choose a scope and maintain what it offers.

Begin with recurring friction

Find a task several teams repeat: creating a service, obtaining an environment, adding observability or preparing a deployment. Observe the waits, workarounds and manual hand-offs.

The first paved path can be small: a repository template, verified pipeline, infrastructure configuration and documentation behind a simple entry point. It should create a usable outcome and state its boundaries. Teams may still take another route, but the exception becomes a visible decision.

Separate portal from platform

A portal is an entry point. The platform also includes the APIs, automation, policies, environments and people that make the journey work. Backstage can support that experience, but it is not a platform strategy on its own.

Backstage Software Templates can collect inputs, create a skeleton and publish it to a source repository. That is useful when the template is maintained and its actions work end to end. A stale catalogue, or a form that only creates a manual ticket, moves friction elsewhere.

Write the service contract

For each capability, state what the platform provides, what the product team owns and how support works. Include compatibility, upgrades, secret handling and retirement.

Put repeatable controls in the path: repository conventions, dependency checks, deployment, minimum telemetry and ownership metadata. Leave business decisions with the team that understands the product.

Measure actual use

Catalogue entries are not proof of adoption. Ask whether teams choose the path when they have an alternative, how long it takes to reach a working deployment, where users abandon it and which support requests recur. Add short interviews: an event shows that a template ran; a conversation explains why the team stopped using it.

Start with a few willing teams. Fix the journey, document exceptions and then open it more widely. The useful question is not “which IDP should we install?” It is “which shared source of friction can we remove and maintain as a product?”

Official sources

• CNCF Platforms White Paper, CNCF, accessed 7 September 2026.
• Backstage Software Templates, Backstage, accessed 7 September 2026.