Four Ways Organisations Build Internal Developer Platforms

Here's the problem in one line. Engineers constantly need things: a database, a test environment, a way to ship code. Getting them usually means asking another team. Then waiting.

That waiting is one of the most expensive hidden costs in tech. Highly paid people, blocked on internal bureaucracy.

An Internal Developer Platform (IDP) is whatever a company builds to end the waiting.

But ask five companies to show you "the platform" and you'll see five different things. A wiki full of snippets. An ancient build server. A shiny portal. A Slack channel called #infra-requests.

These aren't five maturity levels of one thing. They're four different strategies. I've built working versions of each (they're on my GitHub). Here's the honest comparison.

One analogy carries us through: how do you feed your employees?

  • Ticket queue = a canteen clerk takes your order. Come back Thursday.
  • Golden modules = a warehouse of meal kits. Great ingredients, you cook.
  • GitOps = an order form that a robot kitchen fulfils. Exactly. Slowly.
  • Portal = a vending machine. Press button, get meal.

Level 0: The ticket queue

No platform. Just an ops team and a queue. Need a database? File a ticket. Someone with production access makes it exist.

Pluses: Zero engineering investment. A human reviews every change. For a five-person company, this is correct.

Minuses: It scales with headcount, not tooling. Every request interrupts one person and blocks another. And the knowledge lives in heads, not code. Every departure is an outage risk.

Everyone agrees this stage should end. The fight is over what replaces it.

Approach 1: Platform as a library (golden modules)

The first real move for most orgs. The platform team ships high-quality building blocks. Developers assemble them.

The blocks are things like Terraform modules (Terraform: code that describes servers, so infrastructure can be reviewed like software) and ready-made deploy pipelines. This is the meal-kit warehouse. Great ingredients. You still cook.

My gke-production-patterns and practical-aks repos are built this way. Opinionated, production-shaped, meant to be copied.

Pluses:

  • Low buy-in. Teams adopt one block at a time.
  • Everything is versioned and reviewable, like any code.
  • The platform team stays small. They ship artifacts, not a service.

Minuses:

  • Developers still have to cook. Using the library means understanding Terraform, cloud permissions, and plumbing. The friction moved. It didn't disappear.
  • Copy-paste drift. Team B forks Team A's module and quietly edits it. Eighteen months later, "the standard" describes nothing in production.
  • No live inventory. The library says how things should be built. Nobody can answer: what's actually running, and who owns it?

Approach 2: Platform as a pull request (GitOps)

Now the interface changes. Developers stop running tools. Instead, they edit a shared repository that describes what should exist. A teammate approves the change (a "pull request"). Then software like ArgoCD or Flux reshapes the real infrastructure to match. Automatically.

This is the robot kitchen. Fill in the form. Get a sign-off. The machine cooks exactly what the form says.

My terraform-k8s-argocd-cicd-pipeline repo runs this way. vcluster-platform goes further: every team gets a private Kubernetes environment, provisioned by pull request.

Pluses:

  • The audit trail is the change history itself. Every production change has a name, a time, and a reviewer. Compliance conversations get short.
  • Undo is built in. Revert the change, the robot un-cooks the meal.
  • No UI to build. The platform team ships automation and repo structure. Standard dev tooling does the rest.

Minuses:

  • Slow, indirect feedback. You submit the form. You wait. If something breaks, you go hunting through the robot's status screens. Nothing you did appears to do anything. Newcomers hate this.
  • The paperwork gets thick. A hundred services, four environments each. That's a mountain of config files nobody can navigate without tribal knowledge.
  • Poor discoverability. The repo shows what's declared, not what's on the menu. "How do I get a database?" still gets asked in Slack.

Approach 3: Platform as a product (portal + control plane)

The full IDP. A self-service portal in front. An orchestration engine behind it. This is the vending machine: press button, get meal.

I built an end-to-end version in kratix-platform. Backstage (an open-source portal from Spotify) is the storefront. Kratix is the engine that turns a button press into running infrastructure. A developer clicks a template. Ninety seconds later a database exists, catalogued, visible on their dashboard.

Pluses:

  • Actual self-service. The golden path is a form, not a runbook. Nobody needs to understand the machinery.
  • The catalog finally answers "what exists and who owns it."
  • You can run the platform like a product. Measure adoption. Retire old offerings. Evolve interfaces like contracts.

Minuses:

  • You now operate a complex system whose only customer is your own company. My hardest bug in the Kratix build: one component checked its storage backend a few seconds too early, gave up, and never retried. Every status light stayed green. Nothing ever came out. The vending machine broke, silently, while insisting it was fine. That's the class of problem you own at this level.
  • Backstage is a full-time job. It's a framework, not a finished app. Expect custom plugins and upgrades forever.
  • The floor is high. Approaches 1 and 2 deliver value with one engineer. This needs a team. And if the vending machine is even slightly less reliable than the clerk it replaced, developers will walk past it. Then you maintain both.

The housing question underneath all of this

Whatever the interface, a Kubernetes platform must decide: what does each team actually get?

The classic options are extremes. A dedicated cluster per team is a private house. Full privacy, painful cost, slow to build. A shared namespace is a room in a big shared house. Nearly free, but everyone shares the plumbing. And the blast radius.

The middle path, which I explore in vcluster-platform, is the virtual cluster. Technically: a full private Kubernetes control plane running as a small program inside a shared host. The team sees their own building, their own keys, their own rules. The landlord sees one modest tenant using a third of a gigabyte of memory.

A very good sublet, at one percent of the rent. It makes "every team gets a cluster" affordable for orgs that could never justify it before.

So which approach is right?

They're not competing philosophies. They're stages of earned complexity.

  1. Start with meal kits. Ship building blocks the moment the ticket queue hurts.
  2. Move to the robot kitchen when you need audit trails and a single source of truth more than speed.
  3. Build the vending machine only when developers are drowning in the first two, and you have a team ready to run the platform as a real product.

The failure mode: skipping the evidence. Building a portal because conference talks made it look mandatory, when the actual bottleneck was three missing Terraform modules.

The platform is not the portal, the pipeline, or the cluster. It's whatever removes the ticket queue without becoming a worse one.