Why do most internal developer platforms fail to get adopted?
Most internal developer platforms (IDPs) fail adoption because they are built as mandated infrastructure, not as a product developers choose. Teams ship a portal, declare it the standard, and discover engineers still route around it. Industry surveys and practitioner reporting put the failure share high, often cited near two-thirds to three-quarters, but the mechanism matters more than any exact figure.
The recurring root causes:
- ▸No user research. The platform solves the platform team's problems, not the developers'.
- ▸The golden path is slower than the shell script and copied YAML it replaced.
- ▸It is mandatory but optional in practice, nothing makes the paved road the path of least resistance.
- ▸No product owner, no metrics, no roadmap, it is treated as a project that ends, not a product that lives.
Treat any specific percentage as directional and verify current figures against primary sources such as the CNCF platform engineering community and DORA reports. The point stands regardless: a platform nobody chooses is shelfware with a Kubernetes bill.
What does treating the platform as a product actually mean?
It means the platform has users, a product owner, a roadmap, and adoption metrics, the same as any external product, except your customers are your own engineers. You run discovery interviews, ship a minimum viable platform, measure whether people use it, and iterate. If developers route around it, that is a product failure to fix, not user error to scold.
Concretely, treating the platform as a product means:
- ▸A named product owner accountable for adoption, not just uptime.
- ▸Discovery before building, shadow how teams deploy today and find the real friction.
- ▸A public roadmap and changelog so developers trust the thing is going somewhere.
- ▸Support and docs that are actually good, because a paved road with no signage gets ignored.
This reframing is the single highest-leverage change. It is also why our piece on platform engineering golden paths developers actually choose keeps returning to opt-in, not mandate.
What makes a golden path developers actually choose?
A golden path developers choose is the fastest, safest way to do a common task, so obviously easier than the alternative that opting out feels like extra work. It is opinionated, self-service, and complete: create a service and get a repo, pipeline, environments, observability, and secrets wired up in minutes, with secure defaults already baked in.
The properties that make a path win:
- ▸Faster than the workaround. If a golden path takes longer than copy-pasting from another repo, it loses. Full stop.
- ▸Self-service and immediate. No ticket, no waiting on the platform team.
- ▸Complete, not partial. It covers the whole task, including the boring parts, CI, secrets, monitoring, rollback.
- ▸Secure by default. Golden paths are also a security control; the safe choice becomes the easy choice, an idea we develop in golden paths as a security control.
- ▸Escape hatches exist. Developers can drop to the underlying tools when the path does not fit, so it never becomes a cage.
How do you measure whether an IDP is working?
Measure adoption and delivery outcomes, not feature count. Track how many teams use each golden path, how long a new service takes to reach production, and the four DORA metrics, deployment frequency, lead time for changes, change failure rate, and failed-deployment recovery time. If adoption is flat while headcount grows, the platform is losing.
Metrics worth wiring in from day one:
- ▸Golden-path adoption rate, what fraction of new services and deploys go through the paved road.
- ▸Time to first deploy for a brand-new service, measured in minutes and hours.
- ▸DORA four keys, read as a trend, not a scoreboard to shame teams with.
- ▸Developer satisfaction via lightweight surveys, the qualitative signal that explains the numbers.
- ▸Cognitive load, how many tools and steps a developer must hold in their head to ship.
Adoption is the honest metric. A platform can be technically elegant and still fail every one of these; if so, you built the wrong thing well.
Which tools build an internal developer platform in 2026?
There is no single IDP product; you assemble one. Common building blocks are a developer portal (Backstage, Port, Cortex, or OpsLevel), a control plane or orchestrator (Crossplane, Humanitec, or Kratix), GitOps delivery (Argo CD or Flux), infrastructure as code (Terraform or OpenTofu), and policy engines (OPA/Gatekeeper or Kyverno) for governance.
A representative 2026 stack:
- ▸Portal and catalog, Backstage (CNCF, widely adopted) or a managed option such as Port, Cortex, or OpsLevel for a faster start.
- ▸Scaffolding, Backstage software templates or Kratix Promises to turn "create a service" into one action.
- ▸Delivery, Argo CD or Flux for GitOps, the backbone described in GitOps at scale with Argo CD.
- ▸Provisioning, Crossplane or Humanitec to expose infrastructure as self-service, with the open Score spec for workloads.
- ▸Governance, OPA/Gatekeeper or Kyverno for policy-as-code, plus Vault or external-secrets for secret handling.
Buy the portal, build the golden paths; the paths are your differentiator, not the shell around them.
How should AI be wired into the platform with governance?
Wire AI in as a first-class golden path with guardrails, not a free-for-all. Give developers sanctioned ways to add LLM features, approved models, a gateway, and scoped credentials, through the platform, and let AI assist platform tasks such as generating manifests or triaging incidents. The governance is what makes it safe: least privilege, audit, and policy checks on every AI-touched path.
The governed pattern:
- ▸A sanctioned model gateway so teams do not each wire up their own keys and leak them, the alternative is shadow AI, a gap we cover in shadow AI governance.
- ▸Scoped, short-lived credentials for any agent, following the principle of least privilege.
- ▸Policy-as-code on AI paths, the same OPA or Kyverno checks that govern the rest of the platform.
- ▸Provenance and audit, log prompts, tool calls, and outputs so an AI-driven change is traceable.
AI belongs on the paved road precisely because the paved road is where you can govern it. Off the road, it becomes ungoverned risk.
What is the minimum viable platform to start with?
Start with one golden path for your most common task, usually create and deploy a standard service, end to end, for one or two willing teams. Do not build a portal first. Prove the paved road is genuinely faster, earn adoption from real users, then expand paths one at a time based on what those teams ask for next.
A sane sequence:
- ▸Pick one high-frequency workflow and shadow how teams do it today.
- ▸Automate it completely, repo, pipeline, environments, observability, secrets, rollback.
- ▸Skip the portal until you have two or three paths worth cataloguing; a portal over one path is a menu with a single item.
- ▸Recruit design partners, not a mandate; let their success pull the rest of the org in.
Ephemeral, on-demand environments are a strong early win here, see ephemeral preview environments.
How TuniCyberLabs helps
We build internal developer platforms as products: discovery with your engineers, one golden path proven end to end before any portal, adoption and DORA metrics wired in from the start, and AI added on the paved road with least-privilege access and policy-as-code. The result is a platform developers choose because it is genuinely the fastest safe way to ship.
Thinking about an IDP but wary of building shelfware? Talk to our platform team.