Every platform team starts with the temptation to boil the ocean: "we'll abstract Kubernetes, Terraform, all three clouds, observability, CI/CD, security policy, secrets — and ship the unified portal in Q2." That platform never gets built. Or worse, it gets built but nobody uses it.
The Thinnest Viable Platform (TVP)
The TVP, popularised in Team Topologies, is the minimum platform that meaningfully reduces cognitive load for stream-aligned teams. Start small. Pick the single most painful, repeated, undifferentiated piece of work — and remove it.
Heuristics for picking it:
- Frequency. Something every team does every week, not every six months.
- Pain. Currently consumes hours, frustrates developers, or generates incidents.
- Undifferentiated. Every team solves it the same way; nothing about how you solve it is unique to the company.
- Solvable. Real solutions exist; you can ship something useful in a quarter.
Typical TVPs:
- A service template that scaffolds a new microservice with logging, metrics, healthchecks, CI, and a deploy pipeline pre-wired
- A self-service way to provision a database in a sandbox account
- A standard observability stack with default dashboards and alerts
- A "deploy this PR to a preview environment" button
What a TVP is not: an all-singing developer portal. Backstage with 100 plugins. A bespoke abstraction over Kubernetes. Those come later — if they come at all.
Golden Paths
Spotify coined the term Golden Path in 2014. The Spotify memo defined it as:
An opinionated and supported tutorial that walks users through developing something specific.
The key words are opinionated and supported. A golden path makes a choice on the developer's behalf — "use this language, this framework, this template, this deployment pipeline" — and the platform team commits to keeping that path working and current. Off the path, you are on your own.
Spotify's first golden paths covered things like "build a new Java backend service on the JVM platform." The whole journey — bootstrap repo, CI, deploy, observability, runbook — was paved.
Paved Roads, Dirt Roads, Off-Roading
Netflix popularised the metaphor: not every team needs the platform. There are three lanes:
| Lane | Who uses it | Platform team's role |
|---|---|---|
| Paved road | Most product teams | Full support, fast adoption, observability and security built in |
| Dirt road | Teams with specialised needs | Some shared building blocks; team owns more themselves |
| Off-road | Edge cases, experiments, research | Hands off; team owns end-to-end; documents the experiment |
The political move is to make the paved road so good that it is genuinely the easiest path — not to force everyone onto it. Mandates breed resistance; well-designed defaults breed adoption.
Optionality Kills Platforms
Every option you offer is a tail to support forever. Three CI systems is three runbooks, three security reviews, three sets of dashboards. Be ruthless about defaults:
- One CI/CD system, not three
- One Kubernetes flavour, not four cloud variants
- One observability stack with one query language
- One service template per supported language
You will be told "we need flexibility." Some of it is real; most is a request to defer the decision. Make the decision.
Designing the Thinnest Path
Take "scaffold a new service" as a worked example. The thinnest viable golden path:
- A CLI or portal action:
my-platform new service my-svc --language go - That creates a Git repo from a template
- With CI configured (GitHub Actions or whatever your one CI is)
- With a Dockerfile that follows the company standard (distroless base, non-root user)
- With a Helm chart or Kustomize that deploys to a default namespace
- With dashboards, alerts, and runbooks pre-registered
- With ownership wired in Backstage
You can ship the first three steps in two weeks and start collecting feedback. Lock in the next four over the following quarter, driven by what real teams hit.
Iteration Cadence
Treat the platform like any product:
- Weekly office hours for users
- A roadmap on a public Confluence / Notion page
- Adoption dashboards (how many teams onboarded; how many services on the paved road)
- Quarterly developer survey; categorise responses; close the loop publicly
Anti-Patterns
- The Universal Abstraction: "We will hide all clouds behind one API." Inevitable leaks, double maintenance, lowest-common-denominator features.
- The Magic Box: a single CLI command that silently runs hundreds of things. Brilliant when it works; impossible to debug when it doesn't. Expose the steps.
- The Beautiful PR: two years building the portal nobody asked for while teams burn on a CI problem that could be fixed in a sprint.
- The Frozen Platform: shipped, declared done, stagnates. Developer expectations move; the platform must too.
The Bottom Line
Pick one painful, repeated, undifferentiated problem. Solve it well — opinionated, supported, easier than the alternatives. Measure adoption. Expand from there. The platform you do not yet have but want to build is not the platform that will succeed; it is the platform you can ship in a quarter and improve every week.