Platform teams love building platforms. That is the trap. The most common way to fail a platform initiative is to lock yourself away for eighteen months, design "everything at once," and unveil a monument no one uses — because it arrived late and solves yesterday's problems. The alternative is called the thinnest viable platform (TVP), and it demands a shift in mindset: from "infrastructure project" to "product."
A golden path is not a scaffolder
First, the terms. A golden path (Netflix's paved road, Thoughtworks' paved path) is the recommended, platform-team-supported way to solve a routine task: create a service, attach a database, set up monitoring. The key word is supported. Deviations are allowed, but the team that deviates carries the support cost itself.
This is where everyone trips over scope. A golden path is not "the scaffolder created a repo." It is an end-to-end route: code → CI → registry → deploy → monitoring → on-call. If your "golden path" ends at a generated Dockerfile, you built a template, not a path. A real path carries a developer all the way to a production service with HPA, PDB, NetworkPolicy, dashboards, multi-burn-rate SLO alerts and a filled-in runbook already in place — without a single decision that can be made wrong.
A mature golden path has four properties: it is optional (the platform makes the right path the easiest, not the only one — coercion kills innovation), end-to-end, versioned (go-microservice-v2, -v3; old versions are deprecated, not deleted) and owned by a specific team inside the platform org.
TVP: start with one path for one team
The temptation is to cover every language, every scenario, every cloud before the first user. TVP inverts the order: pick one golden path for one team, ship it, document the pain, expand from it. The success metric is not "how many features the platform has" but a simple question: did the team choose this path, or use it because they were forced to? If they chose it freely, the path works. If not, you built internal bureaucracy with a nice portal.
It follows that adoption rate matters more than any technical metric. Drift rate (how many services left the path after launch) and time-to-prod are diagnostics; voluntary choice is the diagnosis.
Standardize first, automate second
TVP has a built-in safeguard that is easy to ignore in a hurry: automating a broken process simply makes failure faster and more consistent. The classic case is a five-thousand-line bash script for AWS provisioning, replaced by Crossplane. It worked not "because automation" but because the correct declarative end-state was formalized first, and only then was the transition to it automated.
The symptom of a violation is recognized instantly: the golden path describes an ad-hoc sequence ("first apply this, then edit the ConfigMap, then restart…") instead of a declarative end-state. The cure is to fix the end-state first (a Crossplane composition, an ApplicationSet, a Helm chart with smart defaults), and only then write the automation glue.
The narrow, boring stack as the opposite pole
There is a second way to build a paved road, opposite to the "self-service buffet": a narrow, boring, opinionated default stack. Amazon's internal teams live by a decision tree: Lambda by default → if you hit the limits, ECS on Fargate → EC2 for legacy only; state is DynamoDB, the glue is S3, IaC is CDK. Not "pick any tool from an exhaustive catalog" but "here are two options, both of which we know how to fix at three in the morning."
The logic is the same as a golden path, taken to the limit: sprawl is the real enemy of systems that outlive the teams that built them. A few standard patterns beat a multitude of individually justifiable choices. Constraints here are guardrails, not a cage: Lambda's limits force you to think about chunking and idempotency early. A telling anecdote from practice: an Aurora database was spun up for a single researcher; years later the researcher was gone, the database lived on. That is operational debt that outlives people — exactly what a narrow stack prevents.
What to take away
A golden path is a product, not a utility: it has an owner, versions, users you cannot coerce, and a metric of voluntary choice. Build it the TVP way — thin, for one team, expanding from pain — standardize the process before you automate it, and remember that sometimes the best golden path is not the most flexible but the most boring. A platform people use reluctantly costs more than no platform at all: you pay both for the infrastructure and for the workaround the teams will build anyway.