Most platform teams build infrastructure. The ones engineers love build golden paths. A guide to building opinionated, self-service paths from code to production.
What Is a Golden Path?
A golden path is the opinionated, paved route your platform team builds so that product engineers never have to make the same infrastructure decision twice. Not a restriction. A reduction of cognitive load.
The term comes from Spotify's platform engineering work, but the idea is universal: when you build a platform, you are in the business of making the right choice the default choice. Golden paths are how you do that at scale.
Every team reinvents the same deployment pipeline.
Every new service takes a week before it can ship anything. Decisions that should be made once are made a hundred times.
A new service goes from idea to production-ready skeleton in under a day.
Decisions already made. Standards already baked in. The developer picks a template, fills in a name, and gets a fully wired service.
Most companies have a platform team. Far fewer have golden paths.
That's the difference between infrastructure and developer experience. Infrastructure keeps the lights on. Golden paths let engineers move.
The Anatomy of a Golden Path
A golden path is not a single tool or a single pipeline. It's a system of five interlocking components. Remove any one of them and the path becomes a trail — possible to follow, but slow and uncertain.
How to Build One (Without Starting From Scratch)
You don't need to build the perfect golden path on day one. You need to build a useful one. Here's the five-step process we use with clients.
Pick your highest-frequency service type
Start with the thing engineers create most often. For most teams, that's a REST API or a background worker. One path done well beats five paths done poorly. The goal of the first sprint is a working template that a senior engineer would actually use — not a comprehensive platform.
Interview three engineers who will use it
Ask what decisions they make every time they start a service. Those are your path's scope. Don't ask what tools they want — ask where they lose time. The interviews take two hours. They'll save you six months of building the wrong thing.
Build the template, not the docs
A working Cookiecutter or Backstage template beats a 40-page runbook every time. Documentation describes the path. A template is the path. Build the template first, then add just enough documentation to explain the escape hatches.
Wire observability in before you ship it
If a developer has to add logging themselves, the path isn't paved yet. Observability is the last thing engineers think about and the first thing they miss when it's absent. Make it non-optional by making it invisible — baked into the template, not bolted on after.
Measure adoption, not completion
Track which paths are used in production. If a path has 0% adoption after 60 days, find out why before building the next one. The most common reason: the path solves a problem the platform team had, not a problem the developers have.
