Your Internal Developer Platform Is Just a New Bottleneck

Your Internal Developer Platform Is Just a New Bottleneck

Nine in ten engineering organisations now report running an internal developer platform. Backstage portals, golden paths, standardised CI/CD, self-serve infrastructure. The pitch is always the same: give developers everything they need in one place, so they stop waiting on platform teams.

And yet the most common complaint from developers has not changed. They are still waiting. Still raising tickets. Still blocked by a process they did not design and cannot change. The bottleneck has a different name now. It lives inside the platform.

You didn't fix the queue. You moved it.

The original promise of an IDP was eliminating "ticket ops": the frustrating cycle where a developer raises a Jira ticket to get infrastructure provisioned, then waits two days for someone on the ops team to run some Terraform.

But here is what most organisations actually built: a new ticket ops queue, dressed up as self-service. Instead of waiting for DevOps to provision something, developers now wait for the platform team to update a template, unblock an approval, or extend the golden path to cover their edge case. Same queue. Different Jira board.

The evidence backs this up. According to Port.io's State of Internal Developer Portals, only 6% of developers report being very satisfied with their current internal tooling. Just 15% say they have clarity on the standards they are expected to follow. These are not the numbers of a system that has eliminated friction. They are the numbers of a system that has institutionalised it.

Gartner has documented the same gap in concrete terms. AI tools now let a frontend team generate a complete React application in three hours. Getting the AWS infrastructure behind it still takes the platform team two to three days of manual Terraform work. The platform promised to compress that gap. Instead it just made the gap more visible.

The golden cage problem

The failure mode has a name: golden cage syndrome.

An IDP falls into this trap when it is designed for governance and control rather than developer consumption. Platform teams wrap complex infrastructure behind a simple interface, enforce opinionated golden paths, and ship a portal that looks like self-service. The problem arrives when something breaks.

When the abstraction leaks, the developer is trapped. They can see the simple UI but not the underlying system. They cannot diagnose the failure. They cannot reach past the abstraction to fix it. They raise a ticket. The queue reassembles.

As the platformengineering.org analysis of IDP failures puts it: "A rigid platform forces developers to work around you. A flexible one invites them to work with you."

The cage gets built for understandable reasons. Platform teams face real compliance requirements, cost controls, and security mandates. Standardisation is genuinely useful. But when opinionated defaults come without escape hatches, what looks like a platform is actually a constraint with branding.

A related pattern is what critics call the monopoly mindset: platform teams that assume adoption because "it is company policy," removing all incentive to build something developers actually want. This approach keeps the platform alive on mandate rather than value, which is a precarious foundation once leadership changes or developers find workarounds.

AI makes the cage more expensive

Teams investing in AI coding tools are discovering the cage the hard way.

DORA research on platform engineering has tracked what happens when individual developer productivity rises faster than organisational delivery systems. The result is consistent: individual throughput increases, but organisational deployment frequency and lead time stay flat. Code is written faster, then waits longer in the same queues.

The AI amplification problem mirrors what DORA found about developer workflows more broadly: AI tools produce more work, and that work piles up wherever the next constraint lives. If the next constraint is your IDP, a team using AI assistants will hit that constraint harder and faster than they did before.

A frontend developer submitting three times as many pull requests per day does not need a platform that responds on Tuesday. They need one that responds in minutes. Most IDPs were not designed for that throughput, and the gap between what AI makes possible and what the platform can absorb is widening.

What good platforms actually look like

The platforms that work share a simple design principle: they treat the developer as a customer, not a compliance target.

That means a few specific things in practice.

Start with the single most painful thing, and solve it completely. The best IDPs do not attempt to cover CI, observability, security, and cost management all at once. They pick the sharpest bottleneck, eliminate it, and let adoption build from there. A platform that does one thing well earns trust. A platform that does ten things poorly creates another layer to route around.

Make it voluntary, then measure adoption honestly. The most useful test of whether an IDP is working: if you made it optional tomorrow, would developers still use it? If the answer is no, that is important signal. The Fairwinds analysis of IDP pitfalls consistently identifies mandated adoption as a leading predictor of failed platform investments. Platforms survive on value, not policy.

Build escape hatches into the defaults. Opinionated golden paths are a good idea. Opinionated golden paths with no exits are a cage. Every standard should come with a documented way to deviate from it when the use case demands it. Teams that need the override will find it anyway: the question is whether they find one you designed, or one they kludge together themselves.

Treat the platform team as a product team. This means sprint reviews with developer users, roadmaps driven by usage data, and a clear owner who is accountable for the platform's experience, not just its existence. The platform team that never talks to the developers it serves will keep building the wrong things with great conviction.

Forge's POV: the platform should get out of the way

The promise of a platform is that it removes friction between intention and execution. A developer has a change to ship: the platform should make that as close to invisible as possible.

That is the design philosophy behind Forge's approach to developer tooling. Git-driven deploys, branch-based staging environments, no ticket required to get a preview of your change in production conditions. The goal is not to enforce a golden path. It is to make the right path the easiest one.

Most IDPs start from the platform team's problems: governance, cost, compliance. The result is a system optimised for the team that built it, not the team that uses it.

Start from the developer's problem, which is simply: how do I ship this thing, right now, without waiting for someone else? That shift in starting point is the difference between a bottleneck and a platform.