An organisation is building an internal developer platform. What should be in scope, and what is the most common scoping error?

What should be in scope

The things every team needs and nobody wants to build:

• Provisioning — a service with its network, identity, secrets, observability and deployment configured correctly, from a template, in minutes.
• The deployment path, including progressive delivery and rollback.
• Observability by default, with correlation identifiers, standard telemetry and dashboards from the template rather than assembled per team.
• Identity and access for both humans and workloads.
• Guardrails, enforced automatically, so compliance is inherited rather than remembered.
• A catalogue — what exists, who owns it, what it depends on — which is the foundation for almost every other governance capability.

The most common scoping error

Building an abstraction over the underlying platform that hides too much.

The team wants to simplify, so it wraps the infrastructure in a simpler model. Then a team hits a case the abstraction does not express, and has no escape hatch — so they leave the platform entirely, which is the worst outcome for both parties.

The workable shape is an opinionated default with an escape hatch: the common path is simple and declarative, and a team with a legitimate need can drop to the underlying primitives without leaving the platform's identity, observability and policy.

The second error

Building capability faster than adoption. A platform with twelve capabilities and three adopted has spent most of its effort on things nobody uses, and the team is now maintaining all twelve.

Adoption is the success metric. Building one capability that every team uses is worth more than five that one team uses.

What should not be in scope

• Business logic, in any form.
• Anything genuinely differentiating, which belongs with the team that competes with it.
• Capabilities with one consumer, which are that team's to own.

The measure

Time-to-first-success for a new team, the proportion of teams on the paved road voluntarily, and support burden per consuming team — the third being the honest indicator of whether it is genuinely self-service.