Overview

Two posts in, and both have been about a trap. Build an internal platform you can’t staff, or rent a hosted one you eventually outgrow. The most common reply I got was the fair one:

If the constraint is headcount, and I’m not getting headcount, what exactly am I supposed to do on Monday?

That question contains the mistake, and I made it too for years. It treats “platform” and “platform team” as the same noun. They aren’t. DORA’s 2025 research found adoption close to universal — “90% of organizations reporting the use of an internal developer platform and 76% establishing dedicated platform teams”. The interesting part isn’t the gap between those two numbers. It’s that neither one predicts whether the platform is any good.

Having a platform is now table stakes; having a good one is not. DORA is fairly direct about that distinction — in their 2025 data, when platform quality is high the effect of AI adoption on organizational performance is “strong and positive,” and when platform quality is low that effect is “negligible.” The platform existing did nothing. The platform being good did everything.

And what makes it good is smaller and more boring than the org chart: whether there is one obvious, supported way to get a change from a commit into production.

So this post is the constructive one. You don’t need a platform team to have a platform. You need golden paths — and a golden path is far smaller than the thing you’re afraid of building.

You already have a platform

Start here, because it reframes everything: your company already has a platform. It just wasn’t designed.

It’s a Makefile with fourteen targets, four of which still work. A Helm chart that was copied three times and diverged. A CI workflow nobody edits without asking one specific person first. A staging environment that is production-shaped in the ways that don’t matter and wrong in the ways that do. Somewhere in there is a step that exists only in one engineer’s muscle memory.

That is a platform. Every deployment goes through it. It has users, failure modes, and an on-call rotation.

The question was never should we have a platform. The question is whether yours was designed or accumulated — and accumulation is what a small team gets by default, because accumulation requires no decisions and no authority. It’s the path of least resistance, and it’s the reason the two-person team feels underwater without ever having agreed to build anything.

Thin, not thick

The second mistake is scale calibration. When a three-person team hears “platform engineering,” they picture Spotify’s Backstage: a service catalog, scorecards, plugin architecture, a portal with a search bar. Then they look at their sprint, correctly conclude they cannot build that, and go back to answering deploy questions in Slack.

Team Topologies has the useful corrective — the Thinnest Viable Platform. Matthew Skelton’s framing is that “this TVP could be just a wiki page if that’s all you need for your platform,” and the discipline is that “you don’t make it any thicker than necessary.” The point of the thing is reducing the load on the teams shipping product — “platform teams create services that accelerate stream-aligned teams, removing complexity” — not building an impressive artifact.

The corollary matters more than the concept: a platform’s job is to remove decisions, not to add surface area. Every feature you add is a feature you now own, document, and get paged for. A small team’s real advantage is that it can’t afford the thick version, so it’s forced into the one that actually helps.

A portal, for what it’s worth, isn’t the thin version — and it isn’t the whole thing either. Backstage describes itself accurately: “an open source framework for building developer portals,” powered by a centralized software catalog. That’s a real and hard problem, and Backstage is good at it. But a portal describes your platform; it doesn’t execute one — there’s no deployment or promotion layer underneath, by design. If the road doesn’t exist yet, a portal gives you a beautifully indexed view of the fact that there’s no road.

What makes a path golden

A golden path is narrower and more mechanical than “platform engineering” sounds. It’s this: one supported way to take a change from a commit to production that a developer can walk end to end without asking you anything.

Four properties, and the failure mode of each:

One obvious way, not documented options. If there are three ways to deploy and a wiki page comparing them, you don’t have a golden path — you have documentation. A path is a default, and defaults are chosen, not offered.

Defaults over knobs. As a rule of thumb, the path should make the large majority of your services completely boring: same shape, same rollout, same observability, no thought required. The genuinely unusual ones need an escape hatch, and the escape hatch should be explicit and rare. A platform with a knob for everything is a config language, and your developers already have one of those.

It goes all the way to prod. A golden path that ends at staging is a hobby. Deploy, preview, promote — the whole distance, including the boring last mile where most homegrown platforms quietly hand you back a kubectl command.

It’s legible underneath. The path should render into artifacts you could maintain by hand if the road vanished tomorrow — standard Kubernetes objects, a Git commit you can read in a diff. This is what separates a paved road from a black box, and it’s the difference between “we adopted a platform” and “we adopted a dependency.”

DORA’s finding here is unglamorous and rings true: the platform capability most correlated with a positive user experience is giving “clear feedback on the outcome of my tasks.” Not the catalog. Not the plugins. Telling a developer, clearly, whether the thing they did worked. And DORA’s 2024 research put developer independence — “the ability to perform tasks without relying on an enabling team” — at a 5% productivity improvement at both the team and the individual level. Modest per change, compounding across every change your company makes.

Four nouns

Here’s the whole mental model I keep coming back to. It fits in four words developers already understand:

   app  ──▶  environment  ──▶  preview  ──▶  promote
    │            │               │              │
  what you   where it runs   try it before   move the same
   own       (staging/prod)   you merge       artifact forward

App. The one object a developer owns. Not a Deployment plus a Service plus an HTTPRoute plus a ConfigMap plus four annotations — one thing that owns all of those and knows how to render them. Developers should reason about their app in an environment, not about eleven Kubernetes kinds and how they relate.

Environment. A lens on the app, not a separate copy of your infrastructure. staging and prod are the same app seen through different config — namespaces derived from a pattern, per-environment overrides in one place instead of a forked values file. The moment staging is a different app, staging stops predicting production.

Preview. An ephemeral instance per change, and — this is the part teams get wrong — cloned from a stable environment rather than configured from scratch. Previews become a maintenance burden exactly when each one carries its own configuration. If a preview is “staging, plus a few app-wide overrides, minus a lifetime,” it stays cheap: it appears when the PR opens, it’s gone when the PR merges, and nobody thinks about it in between.

Promote. Moving a release, not re-running a build. The artifact that passed staging is the artifact that reaches production — same image, same digest — through gates you chose, automatic where you want speed and manual where you want a human. This isn’t an exotic idea; it’s what Kargo’s model formalizes as “freight” — a bundle referencing specific revisions of images and manifests that stays together as it moves down the pipeline, so that “it passed staging” refers to the same bytes. This is also the noun that ends the 2am kubectl apply: not by discouraging it, but by making it unnecessary and obviously wrong.

Notice what’s not in the list. No catalog. No scorecards. No service graph, no plugin framework, no developer portal. Those are real things that solve real problems at real companies — and they’re also exactly what makes a small team believe a platform requires a team.

Notice too that these are nouns, not products. You can implement app→environment→preview→promote on ArgoCD and Kargo, or on your existing CI with Helm and a lot of discipline. The argument here is about the shape, and the shape is what a developer has to hold in their head.

What it actually buys you

For a two- or three-person team, the change is specific:

  • The “how do I deploy this?” thread stops. Not because you wrote better docs, but because the answer is the same every time and the developer can find it themselves.
  • Drift stops accumulating. One road means one shape. Fifty services on a paved road are a fleet; fifty services each configured lovingly by hand are fifty pets.
  • Onboarding a service becomes a form, not a code review of four hundred lines of YAML by the only person who can spot what’s wrong with it.
  • Your job changes. You stop being a ticket queue and start being road maintenance.

That last one is the whole point. Two engineers cannot service a hundred developers’ bespoke requests — the math has never worked and never will. Two engineers can maintain one road that a hundred developers walk. A platform team doesn’t scale by answering more questions; it scales by making fewer questions necessary.

The part that’s genuinely hard

I’d be repeating the sin of the industry if I stopped there, so — the costs are real, and they’re not headcount.

You have to say no. A paved road only works if it’s the road. Every permanent exception is a second platform you now maintain in parallel, and exceptions arrive with good reasons attached and a senior engineer behind them. This is an organizational problem in a technical costume: without backing, an SRE team can’t create a golden path, only a strongly worded suggestion. If you can’t get that backing, find out before you build anything — it’s cheaper to lose that argument early.

Someone still has to build the road. This is the honest limit of “you don’t need a platform team.” You don’t need one to operate a golden path; you do need something to assemble one. Wiring ArgoCD, Kargo, External Secrets, and Gateway API into a coherent app→environment→preview→promote flow is weeks of work followed by years of tracking upstream. That’s the gap the last two posts kept circling: the components are excellent and free, the assembly is the expensive part, and assembly is what a small team can’t sustain as a side project. Which is an argument for the road being a product you adopt rather than a project you start.

And it assumes Kubernetes. If you’re not on it and shouldn’t be, this essay is for someone else. A small team running fine on a single box needs none of this, and telling them otherwise is how our corner of the industry earned its reputation.

One last trap, in the other direction: you can make it too thin. A wiki page really is a valid TVP — right up until you have previews, several environments, and secrets that differ across them. Past that point the wiki page isn’t a platform, it’s a list of things people are supposed to remember, and it goes stale within a month of being written.

Where this is going

The next post is the one I’ve been building toward: why you’d construct this layer on ArgoCD and Kargo rather than reinventing continuous delivery — with the actual generated manifests, not a block diagram. If the last three posts made the argument for what the middle needs, that one is about how, and it’s where I’d rather be judged.

Until then, a question I’d actually like answered. If you have a golden path that works with a small team — what did you have to say no to in order to keep it? The technical designs get written up constantly. The refusals never do, and I suspect that’s where the real lesson is.