Platform Engineering 2026: Why Your IDP Is Empty (And How to Fill It)

Organizations are investing heavily in platform engineering. They are building Internal Developer Platforms (IDPs), introducing developer portals, creating golden paths, automating infrastructure provisioning, and standardizing CI/CD workflows.

Yet many of these platforms face an unexpected problem: developers are not using them.

The developer portal exists. The infrastructure templates are available. Documentation has been published. Platform teams have spent months building self-service capabilities. But developers continue using their own scripts, requesting infrastructure through tickets, maintaining separate deployment workflows, and bypassing the platform whenever possible.

An IDP can be technically complete and still fail as a product.

The problem is often not a lack of features. It is a lack of developer adoption, practical value, and integration with everyday engineering workflows.

In 2026, platform engineering teams need to move beyond building portals and infrastructure abstractions. They need to create platforms that developers genuinely want to use.

The Empty IDP Problem

An Internal Developer Platform is designed to simplify how developers interact with infrastructure, services, deployment workflows, and engineering tools.

Ideally, a developer should be able to create a service, provision an environment, access approved infrastructure, run security checks, deploy an application, and monitor its performance through a consistent experience.

But implementation does not guarantee adoption.

A platform may have a service catalog with hundreds of entries, but developers may still struggle to find the service they need. It may offer infrastructure templates, but teams may consider them too restrictive. It may provide deployment automation, but developers may prefer existing pipelines because they understand them better.

This creates a gap between platform availability and platform usefulness.

An empty IDP does not necessarily mean nobody has logged in. It means the platform has failed to become part of the actual software delivery process.

Why Developers Avoid Internal Developer Platforms

Before improving adoption, platform teams need to understand why developers are avoiding the platform.

Several common problems contribute to low usage.

1. The Platform Was Built Around Infrastructure, Not Developers

Platform engineering teams often begin by identifying infrastructure capabilities they want to standardize.

They create Kubernetes templates, Terraform modules, CI/CD integrations, cloud provisioning workflows, and service catalogs.

These capabilities are important, but developers do not necessarily think in terms of infrastructure components.

They think in terms of tasks:

• Create a new application.
• Set up a development environment.
• Deploy a service.
• Access application logs.
• Configure a database.
• Troubleshoot a failed deployment.
• Request access to a resource.

If the IDP exposes infrastructure complexity instead of simplifying these tasks, developers may find it easier to work outside the platform.

The solution is to design platform capabilities around developer workflows rather than simply exposing infrastructure tools through a portal.

2. Golden Paths Are Too Restrictive

Golden paths provide recommended ways to build, deploy, and operate applications.

They help organizations standardize security, infrastructure configuration, observability, and delivery practices.

However, a golden path becomes a problem when it does not accommodate legitimate differences between applications.

A team building a simple internal API may need a different workflow from a team operating a high-throughput event-processing service.

If both teams are forced into the same template, developers may spend more time working around the platform than using it.

Golden paths should provide supported defaults, not rigid restrictions that prevent reasonable engineering decisions.

3. The Developer Portal Is Outdated

A developer portal is often the first interaction developers have with an IDP.

If its service catalog contains outdated ownership information, broken links, incomplete documentation, or incorrect deployment details, developers quickly lose confidence.

A portal should provide reliable information about the systems developers actually work with.

This includes service ownership, repositories, dependencies, deployment environments, operational documentation, APIs, and support channels.

A portal that looks polished but contains unreliable information will not become a trusted engineering tool.

4. Self-Service Still Requires Human Intervention

One of the main promises of platform engineering is self-service.

Developers should be able to perform common engineering tasks without waiting for another team to complete manual requests.

But many platforms automate only part of the process.

A developer might create a service through the portal, only to discover that database access requires a ticket. Infrastructure provisioning may be automated, but environment configuration may still require manual approval. Deployment may be standardized, but monitoring setup may remain a separate process.

These gaps create friction.

A self-service workflow should be evaluated from beginning to end. If developers still need to coordinate multiple manual steps, the platform has not fully solved the problem.

5. The Platform Adds More Work Than It Removes

A platform should reduce cognitive load, not introduce another set of processes developers need to understand.

If developers must learn a complicated portal, understand multiple internal abstractions, follow lengthy documentation, and troubleshoot platform-specific errors, adoption will suffer.

The platform should make the easiest supported path the most useful path.

This requires clear workflows, consistent interfaces, useful defaults, reliable automation, and documentation that answers practical questions.

Start With Developer Friction, Not Feature Requests

The fastest way to improve an underused IDP is to identify where developers lose time.

Platform teams should investigate common engineering workflows and identify repetitive tasks that create unnecessary delays.

For example:

This approach helps platform teams prioritize capabilities based on actual demand.

Instead of asking, “What should we add to the developer portal?”, ask, “Which recurring engineering problem should the platform eliminate next?”

That shift makes platform development more outcome-driven.

Build Golden Paths Developers Actually Want

Golden paths are one of the most effective ways to make an IDP useful.

A well-designed golden path provides a complete, supported workflow for a common engineering task.

For example, a new-service golden path could include:

1. Select an approved application template.
2. Create the repository.
3. Configure service ownership.
4. Generate the required infrastructure configuration.
5. Set up CI/CD workflows.
6. Integrate security checks.
7. Configure logging and monitoring.
8. Deploy to an approved environment.
9. Register the service in the developer catalog.

The developer should not need to manually coordinate each step across multiple teams.

However, platform teams should avoid creating dozens of golden paths before validating demand.

Start with the workflows used most frequently. Observe how developers interact with them, identify failure points, and improve the experience before expanding the catalog.

Make the Service Catalog Useful

A service catalog is more than a list of repositories.

It should help developers understand what exists, who owns it, how it operates, and how it connects to other systems.

A useful catalog may include:

• Service name and description
• Owning team
• Source repository
• API documentation
• Dependencies
• Deployment environments
• Runtime information
• Monitoring dashboards
• Operational runbooks
• Security and compliance status

The information should be maintained through automated integrations wherever possible.

For example, repository metadata can help identify ownership, deployment integrations can provide environment information, and observability systems can expose service health.

A catalog that requires developers to manually update every field will gradually become outdated.

The objective is to make the service catalog a reliable source of engineering context.

Integrate the Tools Developers Already Use

An IDP should not force developers to abandon every existing engineering tool.

Most organizations already use source control platforms, CI/CD systems, cloud infrastructure tools, Kubernetes, observability platforms, security scanners, and issue-tracking applications.

The developer platform should connect these systems through a consistent experience.

For example:

• GitHub or GitLab for source control.
• Argo CD or Flux for GitOps-based deployment.
• Terraform or OpenTofu for infrastructure provisioning.
• Kubernetes for container orchestration.
• Prometheus and Grafana for monitoring.
• OpenTelemetry for telemetry instrumentation.
• Backstage or another developer portal for catalog and workflow discovery.

These tools serve different purposes. The IDP should provide an integrated interface and standardized workflows without attempting to replace every underlying system.

A developer should be able to access the capabilities they need without navigating unnecessary complexity.

Automate the Entire Developer Journey

A common weakness in IDPs is automating individual steps instead of complete workflows.

For example, automating repository creation is useful, but developers still need to configure pipelines, provision infrastructure, set up secrets, and register services.

A more effective approach is to automate the entire journey from service creation to production readiness.

Consider a standardized application onboarding workflow:

Service Template → Repository → Infrastructure → CI/CD → Security Checks → Observability → Deployment → Service Catalog

Each stage should be connected to the next.

The workflow should also provide meaningful feedback when something fails. Developers need to understand what happened, why it happened, and how to resolve the issue.

This is what turns a collection of automation scripts into a usable developer platform.

Treat the IDP as a Product

An Internal Developer Platform should be managed like an internal product.

That means having clearly defined users, product goals, feedback channels, adoption metrics, a roadmap, and ongoing maintenance.

Platform teams should regularly speak with developers, observe workflows, and identify where the platform creates friction.

Useful product practices include:

Developer research: Interview engineers and understand the tasks that consume the most time.

Usage analytics: Track which workflows are used, abandoned, or repeatedly fail.

Feedback loops: Make it easy for developers to report problems and request improvements.

Roadmap prioritization: Focus on capabilities that solve recurring problems across multiple teams.

Continuous improvement: Treat templates, documentation, integrations, and workflows as products that require ongoing maintenance.

This approach changes the platform team’s role. It becomes responsible not just for delivering infrastructure capabilities but for making those capabilities accessible and valuable.

Measure Adoption Beyond Portal Logins

A platform can receive regular visits without becoming part of everyday engineering workflows.

For that reason, platform adoption needs to be measured through actual usage and outcomes.

Important metrics include:

Active developer adoption: How many developers use platform capabilities regularly?

Golden path adoption: What percentage of new services are created through approved workflows?

Self-service completion rate: How many tasks are completed without manual platform-team intervention?

Workflow success rate: How often do provisioning and deployment workflows complete successfully?

Time to first deployment: How long does it take a new developer or service to reach a working deployment?

Developer satisfaction: Do developers believe the platform makes their work easier?

Support ticket reduction: Are repetitive requests and manual support requirements declining?

These metrics help identify whether the platform is becoming more useful over time.

Teams can also connect adoption with delivery performance indicators such as DORA metrics, while avoiding the assumption that every improvement is caused by the IDP alone.

Make Security and Compliance Part of the Golden Path

Security is another reason organizations invest in platform engineering.

Without standardized workflows, individual teams may configure infrastructure, permissions, secrets, and deployment policies differently.

An IDP can make approved security practices easier to follow by integrating them into reusable workflows.

Examples include:

• Approved infrastructure templates
• Standardized identity and access policies
• Secret-management integrations
• Container image scanning
• Dependency vulnerability checks
• Infrastructure policy validation
• Audit logging
• Environment-specific deployment controls

The key is to make secure workflows convenient.

If developers must bypass the platform to complete routine tasks, security controls may become inconsistent.

However, platform teams should also avoid treating every security requirement as a reason to block all progress. Clear policies, automated validation, and appropriate approval boundaries can provide a better balance between developer autonomy and organizational control.

AI Can Help Make Developer Platforms More Useful

AI is introducing new opportunities for improving internal developer experiences.

An AI-powered developer assistant can help engineers discover services, understand documentation, troubleshoot deployment failures, explain infrastructure configurations, and navigate platform workflows.

For example, a developer could ask:

“Why did my deployment fail?”

The assistant could retrieve the relevant pipeline logs, identify the failed stage, find the corresponding runbook, and explain the likely cause.

An AI agent could also initiate approved workflows, such as creating a development environment or generating a service configuration.

However, AI integration needs the same security boundaries as the rest of the platform.

An AI assistant should not receive unrestricted access to production infrastructure. Tool permissions, authentication, authorization, approval requirements, and audit logs must remain enforced by backend systems.

The strongest approach is to use AI to make existing platform capabilities easier to discover and operate, rather than introducing another isolated tool that developers need to learn.

Backstage Is a Foundation, Not the Entire Platform

Backstage is widely used as an open-source framework for building developer portals. It provides capabilities such as software catalogs, templates, and a plugin ecosystem.

But deploying Backstage does not automatically create a successful IDP.

A developer portal is one part of the broader platform architecture.

The actual platform also needs infrastructure automation, deployment workflows, identity integration, security policies, observability, service ownership, and reliable operational processes.

Organizations should evaluate Backstage or alternative portal technologies based on their requirements, but the decision should not begin and end with the portal.

The value comes from the workflows and engineering capabilities connected to it.

A Practical 90-Day Plan to Improve IDP Adoption

Organizations with an underused developer platform do not necessarily need to rebuild it. A focused improvement program can help identify and address the biggest adoption barriers.

Days 1–30: Understand Why Developers Are Not Using It

Review platform analytics, conduct developer interviews, inspect support tickets, and identify common workarounds.

Find out which workflows developers avoid and why.

Establish baseline measurements for provisioning time, self-service usage, deployment workflows, and developer satisfaction.

Days 31–60: Fix the Highest-Friction Workflows

Select two or three high-value workflows.

These might include new-service creation, environment provisioning, deployment automation, or observability setup.

Improve the experience, integrate existing tools, simplify documentation, and remove unnecessary manual steps.

Test the workflows with a small group of developers before expanding access.

Days 61–90: Measure Adoption and Improve

Measure actual workflow usage, completion rates, time savings, and developer feedback.

Identify remaining problems and prioritize the next improvements.

Publish a clear platform roadmap that explains what has changed, what is working, and which developer problems will be addressed next.

The objective is not to force adoption through organizational mandates. It is to make the platform valuable enough that developers choose it.

Where Engineering Teams Fit

Building a successful Internal Developer Platform requires expertise across DevOps automation, cloud infrastructure, backend engineering, CI/CD, security, observability, and developer experience.

Teams like GeekyAnts and Thoughtworks work across application engineering and modern technology architecture, making this broader engineering perspective relevant for organizations building or modernizing internal platforms.

The focus should be on connecting infrastructure capabilities with practical developer workflows, creating reliable self-service experiences, and ensuring that platform investments deliver measurable operational improvements.

An IDP Is Only Successful When Developers Choose It

The biggest mistake organizations can make in platform engineering is assuming that building an internal platform automatically creates value.

A developer portal can exist without adoption. Golden paths can exist without usage. Infrastructure automation can exist without reducing developer friction.

The difference between an empty IDP and a successful one is how effectively the platform solves real engineering problems.

Start with developer needs. Automate complete workflows. Integrate existing tools. Keep service information reliable. Build flexible golden paths. Measure actual usage and continuously improve the experience.

In 2026, platform engineering is not about giving developers another place to manage infrastructure.

It is about creating an environment where the easiest way to build, deploy, and operate software is also the most reliable and secure way.

For more, visit our homepage!