Many organizations have invested heavily in Internal Developer Platforms (IDPs), expecting them to simplify infrastructure access, standardize delivery workflows, and improve developer productivity. They introduce developer portals, service catalogs, golden paths, automated pipelines, and self-service infrastructure capabilities. The platform launches successfully, the documentation is published, and the engineering team announces the new developer experience.
Then adoption stalls.
Developers continue using familiar scripts, manually configuring environments, asking platform engineers for help, and bypassing the official workflows. The IDP technically exists, but it is not becoming part of everyday engineering work.
This is one of the most common challenges in platform engineering: building a platform is not the same as building one developers want to use.
In 2026, successful platform engineering requires a shift from infrastructure-centric thinking to developer-centric product design. An IDP needs to solve real engineering problems, reduce friction, and make the preferred way of working easier than the alternatives.
The Empty IDP Problem
An Internal Developer Platform is intended to provide developers with a consistent way to access infrastructure, tools, services, environments, and delivery workflows.
It may include a developer portal, service catalog, CI/CD integrations, infrastructure provisioning, Kubernetes management, observability, security controls, and reusable application templates.
However, organizations sometimes mistake the presence of these components for successful platform adoption.
A portal with hundreds of registered services does not necessarily mean developers are using it. A collection of templates does not guarantee that teams follow the recommended workflows. A self-service interface is not genuinely self-service if developers still need platform engineers to complete most operations.
An underused IDP often shows several warning signs:
- Developers continue creating infrastructure requests through tickets.
- Teams maintain their own deployment scripts.
- Golden paths are ignored or modified extensively.
- Service documentation becomes outdated.
- Developers cannot discover the tools and capabilities available to them.
- Platform engineers remain bottlenecks for routine operations.
- New projects continue using inconsistent configurations.
- Developers consider the platform an additional process rather than a productivity tool.
The problem is rarely that developers dislike standardization. More often, the platform introduces friction without removing enough of the existing friction.
Why Developers Avoid Internal Developer Platforms
Understanding low adoption requires looking at the everyday experience of software engineers.
The Platform Was Designed Around Infrastructure, Not Developers
Platform teams naturally focus on infrastructure capabilities: Kubernetes clusters, cloud resources, networking, identity, deployment pipelines, and monitoring systems.
These are essential, but developers usually think in terms of tasks.
They want to create a service, deploy an application, configure an environment, access logs, or investigate a production issue.
If the IDP exposes infrastructure components without connecting them to these workflows, developers must still understand too much of the underlying platform.
A developer should not need to understand every infrastructure detail simply to create a standard application environment.
The platform should translate infrastructure complexity into usable engineering workflows.
Golden Paths Are Too Restrictive
Golden paths provide approved, reusable ways to build, test, deploy, and operate applications.
They can improve consistency, security, and maintainability. However, a golden path becomes a problem when it assumes every team builds the same type of application.
A template designed for a conventional REST service may not work well for an event-driven application, a data processing service, or an AI-powered backend.
If developers must repeatedly work around the platform to accommodate legitimate requirements, they will eventually stop using it.
The solution is to establish useful defaults while allowing controlled customization.
A golden path should be a recommended starting point, not an inflexible engineering restriction.
Self-Service Is Not Actually Self-Service
Some platforms advertise self-service infrastructure but still require manual approvals, ticket creation, or intervention from platform engineers.
For example, a developer may select a deployment environment through a portal, only to discover that provisioning requires a separate request and several days of waiting.
This creates a poor experience because the platform adds another interface without removing the underlying dependency.
A meaningful self-service workflow should automate the complete operation wherever possible, including provisioning, configuration, permissions, validation, and feedback.
Human approval can remain necessary for sensitive or high-impact operations, but routine tasks should not depend on manual intervention.
The Developer Portal Is Out of Date
A developer portal is useful only when the information it provides can be trusted.
If service ownership, deployment instructions, API documentation, dependencies, or operational links are outdated, developers will return to direct communication and existing documentation.
An inaccurate service catalog can be worse than having no catalog because it creates false confidence.
Platform teams should integrate the portal with source repositories, CI/CD systems, cloud infrastructure, and service metadata so that information is updated through actual engineering workflows.
The Platform Adds Steps Instead of Removing Them
An IDP should make common engineering tasks easier.
If creating a new service requires developers to complete a long form, understand unfamiliar terminology, configure multiple integrations, and navigate several approval screens, adoption will suffer.
The platform should reduce the number of decisions developers need to make for standard workflows.
Useful defaults, sensible templates, automation, and clear feedback are often more valuable than adding another layer of configuration.
Treat the IDP as an Internal Product
The most important change is organizational rather than technical.
An IDP should be managed like a product with users, workflows, feedback, adoption goals, and a roadmap.
Platform engineering teams should understand who uses the platform, what those users are trying to accomplish, and where they experience friction.
This requires regular interaction with application developers rather than relying entirely on infrastructure requirements or leadership assumptions.
A practical internal product approach includes:
- Identifying developer personas and their common workflows.
- Understanding the most frequent sources of engineering friction.
- Prioritizing improvements based on developer impact.
- Maintaining a clear platform roadmap.
- Measuring adoption and task completion.
- Collecting feedback after platform changes.
- Treating documentation and onboarding as product features.
The platform team’s success should not be measured only by the infrastructure it operates. It should also be measured by how effectively developers use the capabilities it provides.
Build Golden Paths Developers Actually Need
Golden paths are among the most valuable components of an IDP when they are designed around real application workflows.
Instead of creating templates for every possible technical configuration, platform teams should begin with the most common engineering patterns.
For example, a platform might provide golden paths for:
Backend services: Standardized application scaffolding, API configuration, authentication integration, testing, containerization, and deployment.
Frontend applications: Project templates, build configuration, environment management, CDN integration, and deployment automation.
Event-driven services: Message broker configuration, event schemas, consumer templates, retry policies, and observability.
Data workloads: Approved data processing environments, storage access, scheduled jobs, and monitoring.
AI-enabled services: Model integration, secrets management, inference configuration, evaluation workflows, and AI observability.
Each golden path should provide a working starting point with sensible defaults and clear extension points.
The objective is to reduce repetitive setup work without preventing teams from making legitimate architectural decisions.
Make the Service Catalog Useful
A service catalog should help developers answer practical questions:
- What services exist?
- Who owns each service?
- Where is its source code?
- How is it deployed?
- Which services does it depend on?
- Where are its dashboards and logs?
- What is its operational status?
- Which team should be contacted during an incident?
A portal that only lists service names does not provide enough operational value.
A useful catalog connects service metadata with repositories, deployment systems, observability tools, ownership information, and architecture relationships.
Backstage is a widely used open-source framework for building developer portals and service catalogs. It can provide a foundation for organizing software components, documentation, ownership, and platform integrations.
However, Backstage alone is not an IDP. The broader platform still needs provisioning, deployment, security, observability, and workflow automation capabilities.
The portal should serve as an entry point into the platform rather than becoming another disconnected tool.
Connect the Tools Developers Already Use
An IDP does not need to replace every engineering tool.
Most organizations already have established systems for source control, infrastructure provisioning, deployment, monitoring, and incident management. Replacing all of them can create unnecessary migration costs and adoption resistance.
A better approach is to connect existing capabilities through consistent workflows.
A platform might integrate:
- GitHub or GitLab for source control and pull requests.
- Terraform or OpenTofu for infrastructure provisioning.
- Kubernetes for container orchestration.
- Argo CD or Flux for GitOps-based deployment.
- Prometheus and Grafana for metrics and dashboards.
- OpenTelemetry for traces, metrics, and logs.
- Cloud platforms for identity, networking, and infrastructure.
- Backstage for service discovery and developer-facing workflows.
The goal is to create a unified developer experience without forcing every team to abandon familiar tools.
Design Self-Service Around Complete Workflows
A self-service capability should not stop at initiating an operation.
Consider a developer creating a new backend service. A complete workflow might:
- Generate a service from an approved template.
- Create or configure the source repository.
- Apply standard build and test workflows.
- Provision the required development environment.
- Configure secrets and service identities.
- Register the service in the catalog.
- Connect deployment and observability tools.
- Provide clear instructions for the next steps.
The developer should receive a usable service rather than a collection of partially completed setup tasks.
The same principle applies to common operations such as creating environments, requesting approved infrastructure, deploying releases, and accessing service diagnostics.
Self-service becomes valuable when it removes dependencies between routine engineering tasks.
Make Security and Governance Invisible Where Possible
A common reason developers bypass an IDP is that security controls are implemented as manual checkpoints rather than automated platform capabilities.
Platform teams should integrate security and governance into golden paths.
For example, a standard service template can include:
- Approved base container images.
- Dependency and vulnerability scanning.
- Secret-management integration.
- Role-based access controls.
- Standard logging and tracing.
- Infrastructure policy checks.
- Artifact signing requirements.
- Deployment approval rules for sensitive environments.
This approach allows developers to follow secure practices by default rather than remembering every requirement independently.
Policy as code can enforce organizational standards consistently across teams and repositories.
The important distinction is that security should be built into the workflow, not added as a separate obstacle after development is complete.
Measure IDP Adoption With Meaningful Metrics
A platform team can report the number of services registered, templates created, or integrations completed. These metrics describe platform activity, but they do not necessarily demonstrate developer value.
A stronger measurement strategy looks at whether the IDP is improving engineering workflows.
Useful metrics include:
Adoption metrics: Active developers, active teams, golden path usage, self-service workflow completion, and repeat platform usage.
Productivity metrics: Time to create a new service, environment provisioning time, deployment preparation time, and developer waiting time.
Reliability metrics: Deployment failure rates, change failure rates, recovery time, and platform service availability.
Experience metrics: Developer satisfaction, workflow friction, support requests, onboarding feedback, and task completion rates.
DORA metrics can provide useful delivery-performance signals, including deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time. They should be interpreted in context rather than treated as isolated measures of platform quality.
The key question is whether developers can complete important tasks faster, more reliably, and with less unnecessary coordination.
Use AI to Improve the Developer Platform Experience
AI is creating new opportunities for IDPs, but it should solve specific developer problems rather than become another feature added for marketing purposes.
An AI-enabled platform might help developers:
- Discover relevant services and internal documentation.
- Understand deployment failures.
- Find the correct infrastructure template.
- Explain unfamiliar configuration files.
- Generate boilerplate code within approved standards.
- Summarize logs and traces during incident investigation.
- Navigate platform documentation using natural language.
AI agents may also assist with routine platform workflows, such as generating pull requests for configuration changes or recommending remediation steps.
However, platform teams should establish clear boundaries around these capabilities. AI-generated changes must pass through existing validation, authorization, testing, and approval controls.
An AI assistant should not receive unrestricted access to production infrastructure simply because it is integrated into the developer portal.
The most useful AI capabilities reduce the time developers spend searching for information and navigating complex workflows.
Why Platform Engineering Initiatives Lose Momentum
Even technically capable IDPs can struggle when the organization does not support them as long-term products.
Several mistakes commonly contribute to this problem.
Launching before validating developer needs: A platform designed without meaningful developer feedback may solve problems that teams do not actually have.
Trying to standardize everything: Excessive restrictions create workarounds and discourage adoption.
Measuring infrastructure instead of outcomes: Counting platform components does not reveal whether developers are becoming more productive.
Ignoring documentation: Poor documentation makes even well-designed workflows difficult to discover and use.
Treating adoption as a launch activity: Developers need ongoing onboarding, support, improvements, and communication.
Building a portal without automation: A polished interface cannot compensate for workflows that still require manual intervention.
Failing to assign ownership: Without a dedicated product and engineering roadmap, platform capabilities can become inconsistent and outdated.
Avoiding these mistakes requires platform engineering teams to balance technical standardization with continuous product improvement.
A 90-Day Plan to Improve IDP Adoption
Organizations with an underused IDP can begin improving adoption without rebuilding the entire platform.
Days 1–30: Understand the Friction
Start by observing how developers currently create services, provision environments, deploy applications, and investigate issues.
Interview teams, review support tickets, analyze platform usage, and identify workflows that create repeated delays.
Prioritize a small number of high-impact problems rather than attempting to improve every platform capability at once.
Days 31–60: Fix the Most Common Workflows
Choose two or three workflows that affect a large number of developers.
Improve their documentation, reduce unnecessary configuration, automate manual steps, and integrate existing tools.
For example, creating a new backend service or provisioning a development environment may be a better starting point than introducing an entirely new platform feature.
Days 61–90: Measure, Iterate, and Expand
Release the improved workflows to a pilot group.
Measure completion time, adoption, support requests, failure rates, and developer feedback. Identify remaining friction and make improvements before expanding to additional teams.
Document the results and use them to prioritize the next stage of the platform roadmap.
This creates a feedback loop in which platform improvements are driven by actual usage rather than assumptions.
Where Engineering Teams Fit
Building an effective Internal Developer Platform requires expertise across DevOps, cloud infrastructure, backend engineering, CI/CD automation, observability, security, and developer experience.
Teams like GeekyAnts, Thoughtworks work across these engineering areas, making its broader product and platform engineering capabilities relevant for organizations modernizing their development workflows. The focus should be on connecting infrastructure automation with practical developer needs, establishing reusable engineering patterns, and building platforms that remain maintainable as teams and systems grow.
For engineering leaders, the objective is not simply to introduce another developer portal. It is to create a platform that removes operational friction while improving consistency, reliability, and engineering autonomy.
The Future of Platform Engineering Is Adoption
An Internal Developer Platform does not succeed because it has a sophisticated architecture or an impressive collection of integrations.
It succeeds when developers choose to use it because it makes their work easier.
That requires useful golden paths, reliable self-service, accurate service catalogs, integrated tooling, automated governance, clear documentation, and continuous feedback.
In 2026, platform engineering teams need to think beyond building infrastructure abstractions. They need to understand the developer experience as carefully as product teams understand customer experience.
The strongest IDPs will not force developers into a platform through policy alone. They will make the approved way of working the easiest and most reliable way to get work done.
The goal is not to build a platform developers are required to use. It is to build one they do not want to work without.
For more, visit our homepage!
Add Comment