Backstage's user base has quadrupled to roughly 2,200 companies. Adoption still plateaus at around 10% of developers per company. Something other than "not enough tooling" explains that gap.
You shipped the internal developer platform. Leadership signed off, the platform team spent two quarters building it, the launch email went out with a Loom demo attached. Six months later, half your engineers still file Jira tickets for infrastructure and avoid the portal you built for them.
If that sounds familiar, the data says it's a pattern, not a one-off. Platform engineering maturity research from platformengineering.org puts the scale of it in numbers: 40.9% of platform engineering initiatives can't demonstrate measurable value in their first year, and 29.6% of platform teams don't measure success at all. The gap sits in strategy, before any tool gets chosen.
Cycloid is one of the platforms that structures itself around exactly that sequencing problem: provisioning first, catalog second. What follows is the failure pattern behind low IDP adoption, drawn from that research plus how platform teams that fix it actually operate.
Why This Keeps Happening in 2026
Platform engineering isn't a hard sell anymore. Every platform team pitch deck has the same slide: golden paths, self-service, reduced cognitive load, faster onboarding. Leadership signs off and approves the budget. Then the platform team builds a catalog, a searchable index of services, owners, and docs, and bolts a provisioning workflow onto it as an afterthought, if at all.
That ordering is the problem. A catalog tells developers what exists. Provisioning lets them use it. The ROI comes from the second half, and most platforms never get there before the goodwill runs out.
Three data points illustrate why:
- Platforms that try to solve everything at launch fail 78% of the time. The ones that start with a single high-pain workflow, usually environment provisioning, don't.
- 76% of engineers report that software architecture cognitive burden hurts their productivity; 52% flag context switching between tools as a primary drain. A portal that adds a new tool to switch to, without removing steps elsewhere, compounds the problem.
- Self-hosted Backstage instances typically need 3–15 FTEs to maintain, with teams spending 30–40% of platform engineering time on plugin upkeep instead of building the golden paths that would move adoption.
(Cycloid's guide to internal developer platforms walks through the full breakdown behind these numbers, including where the catalog-versus-provisioning split shows up in practice.)
Low usage often gets read as developer resistance. In most cases it's simpler than that: the platform optimized for the wrong milestone, a launched portal instead of three fewer days of waiting each week.
Four Reasons IDP Adoption Stalls
1. Trying to launch with everything at once
Ambitious platform teams tend to scope the v1 roadmap around the ideal end state (full service catalog, every cloud, every environment type, RBAC for every team) rather than the one workflow developers hit most often. The result is often a platform that's 80% built and 10% adopted. Teams that instead pick the single most painful, most frequent workflow, almost always environment or infrastructure provisioning, and nail that first tend to see measurable traction 2–3x faster than teams chasing full coverage from launch.
2. The platform doesn't have a product owner
Only 32.9% of organizations have a dedicated Head of Platform role, and that gap tends to show up in what platform teams choose to build. Without someone accountable for adoption or developer feedback loops, teams run purely by engineers can end up shipping features nobody asked for while the unglamorous work (onboarding flows, documentation, in-app nudges) that drives usage gets skipped. Teams with a dedicated platform product manager see 2.3x higher internal adoption than engineer-only teams, and organizations with a Head of Platform report 40% less misalignment between platform investment and the business outcomes leadership cares about.
3. The catalog ships, the automation behind it doesn't
This tends to be the most common failure mode, and one of the least discussed. The portal looks finished. Developers can search for services, see who owns what, read the docs. But when they try to provision something, they're often still filing a ticket and waiting three to five days for a platform engineer to run the Terraform by hand. The interface changed; the bottleneck usually didn't. Developers tend to notice within a week and quietly go back to whatever workaround they used before the platform existed.
4. Adoption isn't measured, so the problem isn't caught early
Without lead time, provisioning time, deployment frequency, and failure rate captured before the platform ships, it's hard to prove the platform is working, and just as hard to catch early that it isn't. Close to a third of platform teams skip this measurement step entirely. The result is that leadership often hears "adoption is a problem" for the first time at the annual budget review, months after the point where it could have been fixed.
What Actually Fixes Adoption: A Provisioning-First Playbook
The teams that break the pattern tend to do the same handful of things, in roughly this order:
Start with the one workflow developers hit weekly, not the platform they want in eighteen months. Environment provisioning is usually it. If developers can spin up an environment in minutes instead of days, that alone changes how they talk about the platform internally, and internal word of mouth drives most voluntary adoption.
Make golden paths the default, not an opt-in. A golden path is a pre-approved template, with security, tagging, naming, and cost policy baked in, that a developer fills out like a form instead of a Terraform module they need to understand. Infrastructure-as-code variables become something a developer can self-serve without reading the underlying HCL.
Put someone's name on adoption. Whether it's a formal Head of Platform or a designated owner, someone needs to treat the platform like a product with users, not an internal tool with a maintenance backlog. That person's job is retention, not just uptime.
Instrument before you launch, not after. Capture provisioning time, ticket volume, lead time, and deployment frequency before the platform goes live so the before-and-after story is real, not anecdotal.
Keep governance invisible. Policy-as-code enforced automatically at provisioning time removes developers from approval queues, instead of adding a review step they wait on. Guardrails should feel like defaults, not gates.
Organizations that get this sequence right report provisioning time dropping from three to five days down to around fifteen minutes, deployment updates arriving roughly 40% faster, and operational overhead cut by close to half. That's the gap between a platform people tolerate and one people choose to use.
Where Cycloid Fits, and Where It Doesn't
Since Cycloid built its research around this exact failure pattern, it's worth naming where the platform itself lands on the spectrum, limitations included.
Cycloid fits teams whose adoption problem matches a specific shape: the catalog works, but provisioning still bottlenecks on the platform team. It's built as a unified self-service portal and orchestration layer rather than a catalog-first product, matching the provisioning-first sequence the adoption data points to. A few specifics worth knowing:
What it does well:
- StackForms turns infrastructure-as-code variables into forms, so developers provision environments without touching raw Terraform, cutting typical provisioning time from days to minutes.
- Golden paths ship as pre-approved deployment templates with security, tagging, and cost policy enforced by default, governance that skips the human approval loop.
- Native multi-cloud governance across AWS, Azure, GCP, and on-prem, plus built-in FinOps and GreenOps observability (pre-deploy cost estimation, carbon tracking), so cost and sustainability aren't a separate tool bolted on later.
- An open-source foundation (TerraCognita, InfraMap, TerraCost) that avoids hard vendor lock-in, a real concern for teams who've watched catalog-only tools become a second silo.
- Cycloid reports typical rollouts landing in around three weeks rather than the multi-year timelines associated with fully custom Backstage builds, with customers citing roughly 50% faster project delivery and 40% lower infrastructure costs and carbon emissions after adoption. (Figures as reported by Cycloid; verify against your own environment before budgeting around them.)
Where it's a worse fit: teams that specifically want Backstage's plugin ecosystem depth and have the 3–15 FTEs to run it, or teams whose real gap is a software catalog and service ownership map rather than provisioning automation. A catalog-first tool solves "developers can't find who owns what" more directly. The provisioning-first gap Cycloid is built around is a different problem: developers who already know what they need and still wait three days to get it.
For a wider view of the category, Cycloid also maintains a running comparison of the top internal developer platforms, worth cross-checking against your own shortlist, and a longer breakdown of platform engineering for enterprise environments specifically, for teams evaluating this at larger scale.
Catalog-First vs. Provisioning-First, at a Glance
| Catalog-first platforms | Provisioning-first platforms (e.g. Cycloid) | |
|---|---|---|
| First thing developers touch | Service directory, docs, ownership map | A form that provisions real infrastructure |
| Typical time-to-value | Months, after catalog and integrations mature | Weeks |
| Governance model | Manual approvals, ticket queues | Policy-as-code, enforced at provisioning |
| Maintenance load | 3–15 FTEs common (plugin ecosystem) | Lower: orchestration, not a plugin marketplace |
| Where adoption stalls | Provisioning still bottlenecks on platform team | Catalog and discoverability can lag if not built out |
Who Should Actually Use This Playbook
Platform teams six to twelve months post-launch with flat or declining active usage. The fix usually isn't a relaunch. Audit whether provisioning is still manual behind a nice UI, and fix that first.
Teams about to start an IDP build from scratch. Resist the urge to scope the full catalog. Pick the one workflow with the most Jira tickets against it and solve that end-to-end before anything else ships.
Organizations without a platform product owner. Decide who's accountable for adoption metrics before evaluating any tool. A better platform with no owner drifts the same way a worse one did.
Teams already deep into a Backstage build with the FTE budget to sustain it. This playbook still applies. Sequence provisioning automation ahead of catalog polish rather than assuming a tool swap will fix it.
Frequently Asked Questions
Why does IDP adoption plateau even after a successful launch?
Because a launched portal and a used portal are different milestones. Most platforms ship a catalog, developers browse it once, but provisioning still runs through tickets and manual Terraform behind the scenes. Developers notice within a week and go back to their old workaround, so adoption plateaus around the fraction of developers who tried it once out of curiosity.
What's the single biggest fix for stalled IDP adoption?
Sequencing. Build provisioning automation for one high-frequency workflow, usually environment provisioning, before investing further in the catalog. Teams that lead with a working golden path see measurable traction 2 to 3 times faster than teams that launch with full catalog coverage and no automation behind it.
Do we need a dedicated Head of Platform to fix adoption?
Not necessarily a formal title, but someone does need to own adoption as a metric. Organizations with a Head of Platform report 40% less misalignment between platform investment and business outcomes, and teams with a dedicated platform product manager see 2.3x higher internal adoption than engineer-only teams.
How do we know if our adoption problem is the catalog or the automation behind it?
Watch what happens after a developer finds a service in the catalog. If they can provision it themselves in minutes, the catalog is doing its job. If they still file a ticket and wait days for a platform engineer to run infrastructure-as-code by hand, the interface changed but the bottleneck didn't, and that's the fix to prioritize first.
What should we measure before launching an IDP, not after?
Provisioning time, ticket volume, lead time, and deployment frequency, captured before the platform goes live. Without a baseline, it's hard to prove the platform is working and just as hard to catch early that it isn't. Close to a third of platform teams skip this step and only hear about adoption problems at the annual budget review.
Is a provisioning-first platform like Cycloid a fit for every team?
No. It fits teams whose catalog already works but where provisioning still bottlenecks on the platform team. Teams that specifically need Backstage's plugin ecosystem depth, and have the 3 to 15 FTEs to maintain it, or whose real gap is service ownership mapping rather than provisioning automation, are usually better served by a catalog-first tool.
The Bottom Line
Low IDP adoption often looks like a developer-experience problem and turns out to be a sequencing one. Teams build the visible half of the platform (the portal, the catalog, the docs) and delay the invisible half that removes waiting time from a developer's day. A lot of platform-buying conversations focus on which tool to pick. The ones that end up with real adoption numbers tend to spend more of that time on build order instead.
Top comments (0)