Most internal developer platforms fail for the same reason: they are scoped as a product the platform team wants to build rather than as the removal of the specific friction product teams hit every week. The result is an elaborate portal that wraps a workflow nobody was blocked on, while the actual bottlenecks — getting a database, getting an environment, getting a service into production with the right guardrails — remain ticket-driven. This article covers how to scope a platform so that adoption is a consequence of it being the easiest path, not a mandate.
Start from the request queue, not the roadmap
Before designing anything, read six months of the platform team's ticket queue and categorize it. The categories with the highest volume and the longest wait times are your first golden paths. This is unglamorous and it consistently produces a better backlog than a workshop, because it measures what teams actually needed rather than what they said they wanted.
- Count requests by type, not by requester — repetition is the signal that something should be self-service.
- Record the wall-clock time from request to resolution, not the hands-on effort; waiting is the cost teams feel.
- Note which requests required judgment and which were purely mechanical. Only the mechanical ones are safe to automate first.
- Look for requests that were abandoned. Those represent work teams routed around, usually by building something unsupported.
A golden path is a default, not a cage
A golden path is the supported, documented, opinionated way to do a common thing — provision a service, add a database, ship to production. The critical design property is that it must be genuinely optional. Teams with a legitimate reason to deviate should be able to, at the cost of owning more of the result themselves. Platforms that enforce a single path with no escape hatch generate shadow infrastructure, which is worse than an inconsistent estate because it is invisible.
What a credible golden path includes
- 1.A service template that produces a repository with CI, health checks, logging, metrics and a deployment manifest already wired up.
- 2.Provisioning of the dependencies that service needs — database, queue, bucket — through the same infrastructure-as-code modules the platform team maintains.
- 3.Environment promotion with the approval and audit behavior the organization requires, applied by default rather than configured per team.
- 4.Observability that works on day one: the service appears in a dashboard and alert routing without the team wiring anything.
- 5.Documentation that describes the escape hatch as clearly as the happy path.
A useful adoption test: if a team can go from an empty repository to a service running in production with monitoring and rollback inside a working day, without opening a ticket, the platform is doing its job.
Self-service environments are where the value concentrates
Of all platform capabilities, ephemeral or on-demand environments tend to return the most. They shorten review cycles, make integration testing realistic, and reduce contention over shared staging — the single most common source of cross-team delay in organizations past about five product teams. They are also the hardest to do well, because they surface every place data seeding, secret handling or third-party integration was quietly manual.
- Decide early whether environments are ephemeral per pull request or long-lived per team; the data strategy differs completely.
- Seed with synthetic or anonymized data. Copying production data into short-lived environments is the fastest way to turn a platform into a compliance problem.
- Budget for teardown. Environments that are cheap to create and expensive to remember to delete become the largest line on the cloud invoice.
- Stub or sandbox third-party dependencies deliberately, rather than letting each team discover the problem independently.
Treat the platform as a product with real users
The platform's users are engineers who have alternatives — they can build their own pipeline, provision by hand, or route around you. That means the ordinary product disciplines apply: a named owner, a public roadmap, versioned interfaces, deprecation notice periods, and a support channel with an actual response expectation. It also means measuring adoption honestly.
- Track the share of services on the golden path, and treat a falling share as a defect report rather than a compliance failure.
- Track lead time from commit to production for platform users versus non-users.
- Track platform-caused incidents separately; a platform that reduces team toil while increasing outage frequency is not a net win.
- Ask teams what they routed around in the last quarter, and why.
Common failure modes
- Building a portal before the underlying automation exists, so the UI is a form that files a ticket.
- Mandating adoption before the paved road is actually smoother than the alternative.
- Versioning nothing, so every platform improvement is a breaking change for someone.
- Owning tenant application code, which turns the platform team back into a request queue.
- Measuring platform success by feature count rather than by lead time and toil removed.
The platforms that work are usually smaller than the ones that were planned. They automate three or four things that every team needed, keep the interfaces stable, and leave room for teams to do something different when the default does not fit.