Internal Developer Platforms: Build the Engine, Not the Dashboard

A software engineer is hired to build a product. In a lot of companies, they spend a sizable slice of the week not building it. The time goes to the machinery around the code: working out how to get a new service running, which configuration files to edit, which dashboard tells them whether last night’s release actually worked, and who to ask when it didn’t. None of that ships a feature, and all of it is the problem an internal developer platform is meant to solve.

The term sounds heavier than the idea. An internal developer platform is just a set of self-service tools a company builds for its own engineers, so they can go from written code to a running service without filing a ticket and waiting days for another team to set it up. The practice of building and running that toolset has a name of its own, platform engineering, and the clearest way into the whole subject is to keep those two things apart: platform engineering is the work; the platform is what the work produces. A team that buys a tool and stops there has skipped the work.

That distinction is the durable idea, because it survives every change of fashion in the tools. The platform is an internal product whose users are your own developers, with its own roadmap and its own backlog. It is never a one-time project you finish and walk away from, and treating it like one is where most of the money gets wasted.

The dozen tools in one engineer’s head

To see what the platform is fighting, look at what a single product engineer is expected to carry. On top of the feature they were hired to write, they are supposed to know how the code gets packaged, how it gets deployed, where the passwords and keys are stored, which of three monitoring dashboards to trust, and what to do at two in the morning when an alert fires. Each of those is a separate tool with its own quirks. Every one of them is a detour that produces no product code.

This load is the real cost, and it is not small. Surveys of how developers spend their time keep landing in the same uncomfortable range: somewhere between a fifth and two-fifths of an engineer’s week disappears into friction that has nothing to do with the product. A platform earns its budget by handing that time back. It does not make engineers smarter; it removes the tax they pay for the privilege of shipping.

The dashboard is the easy part

Here is where most platform projects quietly go wrong. The visible piece of a platform is a portal: a single web page where a developer clicks to spin up a new service, find an existing one, or check its health.

The best-known example is Backstage, the portal Spotify built in-house and then handed to the open-source community, which has since become the default starting point for thousands of companies. A portal is genuinely useful, and it is also the easy part of the job, roughly the visible fifth of it.

The portal is only a front door. The real value is the engine behind it, the machinery that takes a developer’s request and turns it into actual infrastructure: a database, a queue, somewhere to run the code, all wired together correctly for each environment, with no human hand-running the steps. That engine is most of the work and almost none of the glory, which is exactly why teams skip it. They buy a polished front door, bolt it onto nothing, and end up with a catalogue that lists every service and lets developers do nothing but read about them. A front door that opens onto a wall is worse than no door, because it looks finished.

Golden paths: the one idea worth stealing

The single best idea to come out of platform engineering has a plain name: the golden path, the paved and fully supported route from idea to running service. Picture a template that already has logging, monitoring, security checks, and a deployment pipeline wired in, so a developer who takes it goes from nothing to a live service in minutes instead of days. Spotify, which coined the term, described it as the route so well supported that taking it is simply the path of least resistance.

The catch is a trade-off between standardization and freedom. The paved road is fast precisely because it is narrow: it supports one main language, one database pattern, one way to deploy, and stepping off it means the platform stops carrying you. Pave too few roads and your best engineers leave the platform behind; try to pave every road and you build something that supports everything badly and ships nothing well. The discipline is to pave the two or three routes that cover most of the work and to say no, out loud, to the long tail.

The road only works when it is genuinely the fastest one. The moment it is mandated but slower than the workaround, engineers route around it, and the platform team spends its quarters policing compliance instead of improving the road. Every default baked into that path, down to something as basic as how containers (the standard way of packaging software so it runs the same everywhere) get built and run, becomes a choice every team inherits. Even that one decision is more loaded than it looks, as our comparison of Docker and Podman for teams that ship lays out.

When it is actually worth building

None of this is free, which raises the only question worth asking before you start: is the company big enough that the platform pays for itself? A figure that gets quoted a lot is around fifty engineers, but the number is a stand-in for something real, not a hard line. The real trigger is the moment several teams stop sharing context and each starts reinventing the same plumbing. Below that point, a small team usually has enough shared knowledge that a handful of well-kept scripts and a good README do the job, and building a platform just taxes the same small group it was meant to relieve.

There is an honest catch that the people who have done this keep reporting: a new platform tends to slow teams down before it speeds them up. The platform is itself a thing engineers have to learn before it pays off, so the productivity curve dips before it climbs. Pretending that dip away is how platform teams burn their credibility in the first quarter; naming it up front is how they survive to the part where it works.

What “works” looks like has a standard yardstick. The industry measures software delivery with a set of metrics known as DORA, which sit on a simple tension: how fast a team ships against how safely it ships. A platform earns its keep by making delivery faster without making it more fragile, turning a two-week wait for a new service into a same-day, self-served click. That single change, weeks down to hours, is usually what gets a platform funded in the first place.

Where these projects go to die

The two common ways a platform dies are visible early if you know the shape.

The first is the front door that opens onto nothing: a portal that catalogues every service and triggers no real action, so within a few months the catalogue drifts out of date because nobody has any reason to keep it current. The second is over-building before anyone needs it, stacking layers of abstraction for a team that deploys one app to one place twice a week. The platform becomes its own product, detached from what developers actually asked for, adding delay to every change while removing pain nobody was feeling.

The tell for both is the same, and it is simple: no measurement of whether the platform is used. A team that cannot say what share of deployments go through the golden path, or how many services were created from a template last month, is flying blind. Treat the platform as a product and measure whether anyone uses it, or you will not notice it has died until the catalogue is a year stale.

The AI part, kept honest

The newest addition to the pitch is AI, and the grounded version is narrower than the keynote version. What works today is using AI to smooth the most tedious moments: generating the skeleton of a new service, filling in boilerplate configuration, answering “where is the thing that does X” in plain language instead of a wiki search. What is still mostly a demo is the platform that provisions and repairs itself with no human in the loop. AI shortens the on-ramp to the paved road; it does not yet drive the car. Anyone selling you the second thing today is selling the slide, not the product.

Frequently asked questions

How is platform engineering different from DevOps?

DevOps is a culture: the idea that the people who build software and the people who run it should not be separated by a wall. Platform engineering is one concrete way to deliver that idea at scale. Instead of every team running its own operations, a dedicated group builds an internal product that all the teams use to help themselves. DevOps says dev and ops should not be siloed; platform engineering is the staffing-and-tooling model that makes it true once a company is too big for shared habits alone to hold it together.

Do I need Kubernetes to build one?

No, though a lot of the popular tooling assumes it. Kubernetes is the now-standard system for running software in containers across many machines, and it is powerful and complicated. You can build a perfectly good internal platform on simpler foundations with a portal and templates in front of them. If you do not already run Kubernetes, adopting it purely to get a platform is itself the over-building mistake. Match the platform to the machinery you already operate, not to the one in the conference talk.

Is Backstage free, and what does it really cost?

The software is open source and free to download. The cost is operational: Backstage is an application your team has to deploy, keep patched, and extend, which means at least a fraction of an engineer’s time on an ongoing basis. Commercial alternatives charge a subscription in exchange for not running that application yourself. The choice comes down to a familiar one: do you have people who can own and maintain a codebase for the long term, or would you rather pay someone else to?

Why isn’t a normal deployment pipeline enough?

A deployment pipeline runs a fixed recipe to build, test, and ship code. The engine inside a platform sits one step above that: it takes a developer’s request (“this service needs a database and a queue”) and works out the concrete resources for each environment before handing off to the pipeline. The pipeline executes a known recipe; the engine decides what the recipe should contain this time. That deciding step is the part that turns a click in the portal into real, correctly wired infrastructure.

At what team size does a platform make sense?

The widely quoted threshold is around fifty engineers, but the honest trigger is communication overhead, not an exact headcount. Once you have several teams that no longer share daily context and each rebuilds the same setup-and-deploy plumbing on its own, having one group pay that cost once for everyone starts to add up. Below that, well-kept scripts and documentation usually win, because the platform’s upkeep lands on the same small team it was supposed to free.

Build the layer that hurts

The order of the build is the whole decision. If you are below the point where several teams keep reinventing the same setup work, do not build a platform: write the scripts, write the README, and revisit when you have grown into the problem. If you are past it, start at the single workflow that costs your engineers the most this quarter, the two-week wait for a new service or the deploy nobody can run without help, and build only the engine that fixes it. Pave one good road, prove people drive on it, and pave the next only when the first is carrying load. The platform from the conference slide is the one that becomes a graveyard; the one that lasts is the layer that was actually hurting.

---

Photo: cottonbro studio / Pexels