Why IDPs Stall After Initial Adoption

An internal developer platform (IDP) earns trust one workflow at a time and can lose it just as quickly when developers encounter a dead end. A successful launch may bring strong initial adoption, yet usage can flatten once teams discover that the approved paths do not cover their applications, infrastructure, or preferred tools.

The platform team then faces competing demands. Developers want dependable self-service without losing control over how they build, while security and operations teams want consistent policies across a technology estate that still includes mainframes, virtual machines, cloud-native services and a growing collection of AI tools.

An IDP must absorb that complexity without becoming another complicated system developers have to navigate. Sustaining adoption requires continuous product management, carefully chosen standards and evidence that the platform is eliminating work rather than transferring it elsewhere.

Golden Paths Can Become Golden Cages

Golden paths work best when they simplify frequent, well-understood tasks. Problems emerge when the platform team treats the common path as the only acceptable one or allows its templates to fall behind the needs of development teams.

Matthew Flug, research manager for intelligent application modernization and deployment platforms at IDC, says platform teams must continually monitor how developers use the IDP and where they abandon it.

“Golden paths built for the common case can become golden cages that restrict innovation and creativity, leading developers to route around them,” he explains.

Workarounds provide useful product feedback. A team that repeatedly builds its own deployment path may have an unusual requirement, but it may also be exposing a gap that affects other developers. Platform teams need a regular process for reviewing those exceptions, updating templates and deciding whether a new capability belongs in the paved path.

A narrow scope can also help, as the IDP should standardize the workflows most teams use while allowing justified exceptions, rather than accumulating features for every possible use case.

Integration Work Can Recreate the Ticket Queue

An IDP sits above existing tools and infrastructure, which means the complexity hidden from developers still must be managed somewhere. Integrations, exception paths, templates and catalog entries can consume an increasing share of the platform team’s capacity.

“An IDP is a layer on top of existing tooling, not a replacement for it, so the complexity it hides from developers doesn’t disappear; it moves to the platform team as integrations to maintain, exception paths to support, and templates and catalogs to keep current,” Flug says.

Core mainframe environments create friction because teams may need to uncover undocumented dependencies before changing code or connecting new workflows. Large virtual-machine estates present another challenge because many platforms assume a cloud-native foundation and struggle to present traditional, modern and AI workloads through a consistent interface.

Platform teams can limit the maintenance burden by favoring API-based integrations and making templates, policies and catalog information self-maintaining through continuous integration. The objective is to prevent platform specialists from spending most of their time repairing connections instead of improving developer capabilities.

AI Moves the Bottleneck to the Platform

Coding agents can increase developer output without removing delays elsewhere in the software delivery lifecycle. An IDC report found 81% of developers report productivity gains from agentic coding tools, but the resulting volume places additional pressure on platforms to deliver environments, validate changes and enforce governance.

Without sufficient capacity and automation, the IDP can recreate the ticket-based shared-services queue it was intended to replace.

Supporting AI does not require discarding a working IDP. Platform teams can extend it with approved model access, model serving, registries, GPU provisioning, Model Context Protocol infrastructure and connections to authorized agents. API-first components allow those services to be added progressively without the risk and delay of an AI-native rebuild.

The IDP also becomes an interface for machines. Agents need a machine-readable service catalog, retrievable policies and golden paths that they can extend without bypassing the organization’s controls.

“The platform must become the single control point for AI cost and security policy,” Flug says.

Standardize Controls While Preserving Choice

Platform teams need consistency wherever enforcement depends on it. Service ownership and metadata, paved templates, security policies, agent identities, guardrails and approval paths should behave predictably across teams.

Implementation choices can remain flexible when they do not undermine those controls. Developers may need to leave a golden path for a legitimate technical requirement, provided the exception remains visible and governed.

“Golden paths should be blueprints and the principle is guardrails, not barriers, with room to leave the paved path when a use case genuinely requires it,” Flug says. “That balance is crucial because platforms that resolve the tension by mandate get avoided.”

Measure Whether Toil Actually Disappears

Adoption numbers can show whether developers enter the platform, but they cannot reveal how much work occurs outside it or how much maintenance it creates. Platform leaders should track how frequently developers bypass the IDP, how many separate delivery pipelines remain, and how much platform-team capacity goes toward integration maintenance

Other important metrics include measuring how lead time, deployment frequency and production vulnerabilities change and how cloud and AI-agent costs map to specific workloads and tasks

Not only do these measures show whether self-service is reducing friction across the delivery system, but they also expose cases in which developers save time while the platform team inherits additional manual work.

“The true test is whether toil is actually reduced, not simply shifted,” Flug says.