saaro

Posted on Oct 30 Originally published at blog.saaro.net

The Platform Island: Why Nobody Deploys on Our Internal Developer Platform

#kubernetes #devops

Every second company has one. Most have invested six figures. And in almost every case, the most used feature is the password reset link. We're talking about Internal Developer Platforms (IDPs) – the in-house developer platforms that can do everything but are used by no one.

The Platform Island Phenomenon

You know the drill: the company buys or builds a platform. A team of platform engineers works on the architecture for months. There's a fancy UI, CI/CD pipelines, self-service interfaces. The platform is celebrated with a big launch – and then what happens: nothing.

The teams continue to work as before. They use their own scripts, their own workflows, their own directories. The platform becomes a digital ghost town.

Why?

Three reasons why platforms fail

1. The platform doesn't solve a real problem

The most common mistake: the platform was built because management wanted a platform – not because developers had a problem.

A platform that doesn't address an acute pain point will never be adopted. "Look, we have a nice UI for Kubernetes deployments" isn't a value proposition. "Your deployment used to take 45 minutes and three emails to the ops team – now it takes three minutes by a click" is.

2. Too much complexity, too little standardization

Many platforms try to map all possible workflows. The result: they can do everything, but nothing properly. The user interface is overloaded, the documentation is outdated, the interfaces are inconsistent.

The most successful platforms limit themselves to a few, but excellently implemented Golden Paths: well-defined, documented, tested standard workflows for the most common tasks.

3. No migration, no pressure

The biggest hurdle is the existing work: existing projects run with old scripts, Makefiles, and manual know-how. As long as they work, there's no reason to switch.

The platform gets built, but nobody migrates the existing projects. And without migration, the platform remains empty.

What platforms need instead

From observing working platforms (Backstage, internal developer portals at Spotify, Red Hat, Netflix), five principles can be derived:

1. Pain before Platform

Before you build a platform, find out where the pain is greatest. Measure the time teams lose on manual processes. Talk to the developers, not the managers.

A platform that addresses the biggest pain first will be adopted. A platform that can do "everything" will be ignored.

2. Golden Paths, not a workflow engine

Define exactly 3-5 standard workflows that work like a dream. Everything else is secondary.

3. Self-service with a safety net

Developers must be able to use the platform without having to write a ticket. But every action mmust be auditable and reversible.

4. Migration is not an afterthought

One third of the platform budget should go into migration. Automated migration tools, import interfaces, compatibility modes – everything that makes the switch easier.

5. Metrics and visibility

The platform must measure whether it is being used. Number of active projects, deployment frequency, time-to-production. These metrics belong in the management dashboard – and if they stagnate, that is a warning sign.

The counterexample: Spotify and Backstage

Spotify built Backstage because the infrastructure team in 50 teams with different languages, tools, and deployment processes had no standard workflow. The pain was real: a new service took weeks to get through all the checks.

Backstage automated exactly this one workflow: generate service template → connect CI/CD → comply with deployment policies → set up monitoring. No more, no less.

The result: Backstage was adopted internally at Spotify, later open-sourced, led to CNCF graduation – and is today the most widely used Internal Developer Platform in the world. Helen Greul, Head of Engineering for Backstage at Spotify, reported in an interview with The New Stack that Spotify achieved a voluntary 99% platform adoption rate. Her key insight: "With a product that's built for developers, with empathy for developers, they recognize the value."

Why? Because it perfectly automated one workflow – the one with the greatest pain.

Conclusion: Less is more

A successful platform is not a platform that can do everything. It is a platform that does one thing so well that no developer wants to work without it.

If your platform hasn't reached 80% adoption after a year, it's not the developers' fault. It's the platform design. Ask a different question: Not "What can the platform do?" but "What problem does the platform solve for whom – and how do I measure whether it is solved?"

Platform silos are not created by malicious developers, but by platforms that solve problems nobody has.

DEV Community