What an internal developer platform is, and when not to build one

"Internal developer platform" is a term that arrived fully formed and slightly unhelpful. Most engineers meet it as a job title or a conference track before they meet a definition, and by then it has come to mean roughly "the thing our infrastructure team is building."

The useful definition is narrow. An internal developer platform is the supported path from a developer's commit to a running service, packaged so that taking it requires less knowledge than assembling it yourself.

What it replaces

Every organisation has this path whether or not anyone designed it. Without a platform, it exists as a shared understanding: copy the pipeline from the last service, ask which cluster staging is on, find whoever knows how ingress works. It runs on tribal knowledge and on a small number of people who cannot go on holiday at the same time.

A platform makes that path explicit and self-service. The test is not how sophisticated it is. The test is whether a developer who joined on Monday can deploy on Tuesday without booking anyone's time.

What it usually has

• A way to describe a service that is shorter than the underlying infrastructure requires.
• A build and release path that is the same for every service, so knowledge transfers between teams.
• Environments that can be created and thrown away rather than queued for.
• Backing services on request, so a database is a request rather than a project.
• Visibility — logs, metrics and deploy history where the person who deployed can find them.
• Guardrails — who can do what, and a record of who did.

The honest test for whether to build one

Building a platform is building a product, and it has users who are your colleagues and are not shy. The work does not end at launch; a platform is a maintenance commitment for as long as the company runs.

Two questions decide it. First: is the path from commit to production actually costing us more than a team would? If three services deploy fine and the bottleneck is elsewhere, a platform is an expensive answer to a question nobody asked. Second: are our requirements genuinely unusual? Bespoke platforms earn their keep where the constraints are bespoke, such as strict data residency, unusual hardware, or a regulatory boundary no product models.

If the answer to the first is yes and the second is no, you are about to spend a year rebuilding something that exists, and the version you build will have one maintainer.

Where Kaja fits

Kaja is the assembled version of that path for teams running their own Kubernetes clusters. Projects give each piece of work its own space with its own configuration and secrets. Deploys come from a connected repository and every one is a numbered revision you can roll back to. Databases and caches are added from a catalog and bound into apps rather than provisioned by hand. Roles decide who can touch what, and changes are recorded.

What it deliberately does not do is take the cluster away from you. Everything it creates is a standard Kubernetes object in infrastructure you own, so adopting it is not a bet that we will still be here in five years. If you outgrow the assembled path and need the bespoke one, what you built on is still there.

See projects for the unit of isolation, or the feature inventory for what exists today.