Dora NodaYour company probably has an internal developer platform. DORA's research puts internal developer platform usage at 90% of organizations, with 76% running dedicated platform teams. Yet the latest State of Platform Engineering Report — Volume 4, drawing on a global survey of 518 platform practitioners — carries a brutal finding beneath its "platform engineering is now the operating model of the modern enterprise" headline: roughly 70% of internal-platform initiatives fail to reach meaningful developer adoption when they skip a well-designed golden path.
The numbers are worth staring at before any analysis:
| Finding | Number |
|---|---|
| Survey respondents (platform practitioners, global) | 518 |
| Platform initiatives failing to reach meaningful adoption without a golden path | ~70% |
| Voluntary developer adoption when teams invest in a golden path | above 80% |
| Voluntary developer adoption when they don't | under 20% |
| Platform teams that track no adoption metrics at all | nearly 30% |
That 80-versus-20 spread is not a gentle gradient — it's a cliff. And the 30% of teams measuring nothing means nearly a third of platform organizations wouldn't even know which side of the cliff they're on. This post unpacks what a golden path actually is, the mechanism behind the failure rate, the four metrics that close the measurement gap, and an uncomfortable build-vs-adopt question the report's own evidence raises.
What a Golden Path Actually Is (and What It Isn't)
The term comes from Spotify, which defines a golden path as "the opinionated and supported path to build something" — a backend service, a website, a data pipeline — backed by step-by-step tutorials a developer can follow end to end.
Spotify didn't invent it as a branding exercise. As the company scaled, its famously autonomous squads produced what engineers there called "rumour-driven development": the way you learned to ship a service was to ask whoever sat nearby, and every team accumulated its own slightly different stack. The golden path was the cure — one supported way to do each common thing, so well documented that the tutorials became Spotify's most-read technical documentation and part of every new engineer's first two weeks.
The CNCF's platform engineering maturity model gives the concept a ladder. It scores platforms across five aspects — investment, adoption, interfaces, operations, and measurement — over four levels:
- Provisional — ad hoc, voluntary efforts; no consistent path
- Operationalized — a dedicated team ships "paved roads" as documentation and templates
- Scalable — paved roads become self-service, one-click solutions
- Optimizing — the ecosystem manages itself; automation everywhere
Notice what a golden path is not: it is not a service catalog, a wiki, or a portal with forty tiles. A list of options is the opposite of an opinionated path. The golden path is a default — the thing that happens when a developer does the obvious action, like pushing to a git branch — with escape hatches for the 10% of cases that genuinely need them.
Why Platforms Without a Golden Path Fail: The Mechanism
The 70% failure rate isn't mysterious once you trace the causal chain.
An internal platform without a golden path is optional infrastructure. It sits next to everything else a developer already knows: hand-rolled Terraform, the CI scripts from the last project, kubectl apply from a laptop. Using the platform means learning a new abstraction and trusting a young internal product — while the old way still works. Rational developers defer. Adoption stalls under 20%, the platform team's next budget review goes badly, and the initiative joins the 70%.
A golden path inverts the incentive. When the supported path is also the easiest path — push code, get a running service with TLS, logs, and rollbacks — adoption stops being a persuasion campaign. That's the mechanism behind the report's above-80% voluntary adoption figure: nobody mandates a paved road; people take it because it's paved.
DORA's research adds two sharp edges to this picture:
- Platforms are not automatically a win. DORA's 2024 findings show internal developer platforms improve individual productivity, team performance, and organizational performance — but can decrease throughput and change stability when poorly implemented. A platform that inserts a ticket queue between a developer and production is a golden path in reverse.
- Developer independence is the active ingredient. Giving developers the capacity to accomplish tasks without waiting on an enabling team produced a measurable 5% productivity improvement at both individual and team levels. Golden paths work precisely because they are self-service; a "golden path" that requires filing a ticket is just a queue with better marketing.
There's also a 2026-shaped reason the stakes went up. Volume 4's central theme is the rise of AI-native platforms, and DORA's data shows platform quality gates whether AI adoption pays off at all: when platform quality is high, AI's effect on organizational performance is strongly positive; when it's low, the effect is negligible. An unadopted platform is, by definition, low-quality where it counts — so the 70% failure rate now also forfeits the AI dividend the same executives are chasing.
The Measurement Gap: Nearly a Third of Teams Are Flying Blind
The report's second headline finding — nearly 30% of platform teams track no adoption metrics at all — may be the more damning one, because it explains how initiatives stay on the failing side of the cliff for years. Volume 4 frames industry maturity across adoption, investment, and measurement; measurement is where the floor drops out.
The CNCF maturity model describes the progression: measurement starts ad hoc (level 1), becomes consistent collection via surveys and instrumented usage (level 2), matures into insights tied to strategic outcomes (level 3), and finally integrates quantitative and qualitative signals across the organization (level 4). Nearly a third of teams, per the survey, haven't reached level 2.
You don't need a data team to clear that bar. Four metrics cover the essentials:
| Metric | Definition | How to instrument | Healthy direction |
|---|---|---|---|
| Time-to-first-deploy | Minutes from a new user's first git push (or signup) to a live service | Timestamp delta between onboarding event and first successful deploy | Minutes, not days; trending down |
| Deploy frequency | Deploys per service per week through the platform | Count deploy events in the platform's own API/event log | Up and to the right; DORA elite is on-demand |
| Rollback rate | Share of deploys reverted or failed | Failed + rolled-back deploys ÷ total deploys | Low and stable — rising rate flags a stability tax |
| Voluntary adoption | Share of teams using the platform without a mandate | Active teams on platform ÷ total eligible teams, excluding mandated ones | The report's own bar: above 80% is what golden-path investment buys |
Two of these — deploy frequency and rollback rate (change failure rate) — are DORA metrics you'd want anyway. Time-to-first-deploy is the onboarding funnel's moment of truth. Voluntary adoption is the honest one: mandated usage tells you about your org chart, not your platform.
The bar we hold ourselves to: this cuts both ways for anyone shipping a deploy platform, including us at Bex. If nearly a third of platform teams measure nothing, the bar for a git-push PaaS is to instrument its own onboarding funnel with exactly this table: time from git push to a live HTTPS URL as the north-star onboarding metric, deploy frequency and rollback rate read straight from the platform's machine-readable deploy events, and voluntary adoption tracked per cluster rather than assumed. A platform that pitches itself as a golden path and doesn't publish its own time-to-first-deploy number is clearing the same low bar as everyone else.
Build a Second Platform Layer, or Adopt One That Ships With the Golden Path?
Here is the uncomfortable read of the report's evidence: if ~70% of internal-platform initiatives fail on adoption, and the differentiator is a well-designed golden path, then the highest-risk item on your roadmap is building a bespoke platform layer whose golden path you haven't designed yet.
Meanwhile, the golden path the report describes — an opinionated, supported, self-service route from code to production — already has a canonical shape. It's the Heroku workflow: git push, build, run, HTTPS URL. A git-push deploy platform doesn't have a golden path; it is one. That's true of the managed PaaS vendors, and it's true of open-source, self-hosted implementations — Bex, for example, turns a git push into a running HTTPS service on machines you own, with the deploy pipeline, buildpacks, and rollbacks as the paved road rather than a layer you assemble.
So the practical decision isn't "should we do platform engineering" — at 90% IDP penetration, that ship has sailed. It's where your golden path comes from:
- Adopt a deploy platform as the paved road when your workloads are mostly web services, APIs, and workers; when your platform team is small (or is one overloaded DevOps engineer); and when time-to-first-deploy is the metric you most need to win. You inherit an adoption-tested golden path on day one and spend your platform budget on the 10% that's genuinely yours.
- Build a custom IDP layer when you're a large organization with many bespoke internal systems, hard compliance workflows (approval chains, data-residency routing), or a developer population big enough that a dedicated platform-product team can iterate on adoption the way Spotify did. The counter-argument is real: Spotify's golden paths succeeded because a well-staffed team treated them as a product for thousands of engineers. If that's you, build — but staff the golden path first, not the control plane.
The failure mode the report quantifies is the middle path: a mid-sized team building a thin custom layer on top of tools that already had a golden path, adding choice where opinion was needed. That's how you land in the under-20% adoption bucket with a platform nobody asked to leave.
Platform Engineering Is Now the Operating Model — Measure Like It
Volume 4's larger claim is that platform engineering has become the operating model of the modern enterprise, with AI-native platforms, evolving platform roles, and updated reference architectures as the frontier themes. The survey's 500+ practitioners aren't debating whether to have a platform; the 90%-adoption, 76%-dedicated-team baseline settles that.
What separates the winners is embarrassingly concrete. Ship an opinionated golden path — a default so smooth it wins voluntary adoption above 80%. Instrument the four numbers: time-to-first-deploy, deploy frequency, rollback rate, voluntary adoption. And before building another platform layer, ask whether the golden path you'd have to design already exists as a product — because the report's 70% is not a warning about platforms; it's a warning about platforms without paved roads.
The teams flying blind aren't villains. They're busy. But "nearly a third of platform teams don't measure adoption" is the bar the industry is currently clearing — which means measuring at all is, for the moment, a competitive advantage. Take it while it's cheap.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
Sources:
