TL;DR - A platform stays a slide deck until the first golden path ships. Don’t start with a developer portal, a service mesh, or a roadmap. Start with the single most-repeated request your developers make, turn it into a paved road that takes them from nothing to production in a day, and get one team to actually use it. The technology is the easy part. Adoption is the whole job.
I have watched a lot of teams decide to “do platform engineering”. Most of them start the same way: a Notion doc, a target architecture diagram, a six-month roadmap, and a shopping list of CNCF projects. Six months later they have Backstage running, three plugins nobody asked for, and developers who still file the same tickets they filed before.
The teams that succeed start somewhere much smaller and much less impressive. They pick one path - the boring, repeated, soul-destroying thing every developer does the same way and gets wrong in their own personal style - and they pave it. That first paved road is where platform engineering stops being a slide and becomes a thing developers use on a Tuesday.
This post is about how to pick that first path, what actually goes in it, and the part everyone underestimates: getting someone to use it.
What a golden path actually is
A golden path is the supported, opinionated, well-lit way to do a common thing. “Create a new service.” “Add a background worker.” “Ship a cron job.” “Stand up a new frontend.” The path encodes your organisation’s accumulated answers to the hundred small questions that otherwise get answered, badly and differently, by every engineer who has ever done it.
Three words in that definition do the work, and it’s worth being precise about each:
- Supported. Someone owns it. When it breaks, it’s a bug in the platform, not the developer’s problem. This is the difference between a golden path and a wiki page that rotted in 2023.
- Opinionated. It makes the choices for you. Which CI system, which base image, which logging library, which secrets store, which deploy mechanism. The value is precisely in not making the developer choose.
- The way, not the only way. A paved road, not a walled garden. Developers can leave it when they have a real reason. They mostly won’t, because leaving means doing the work the path was doing for them.
That last point is the one teams get wrong most often, so I’ll say it plainly: a golden path is paved, not mandatory. The moment you make it the only legal route, you’ve stopped building a product developers want and started building a compliance gate they’ll resent and route around. You make the easy thing the right thing, and then you let the easy thing win on its merits.
Why the first one is the hard one
The technology of a golden path is not hard. It’s a template repository, a default pipeline, and some sane defaults. A competent engineer can build the mechanics in a couple of weeks - assuming the backends they lean on already exist. If you don’t yet have a metrics and logging stack or a secret store to wire the template into, those are their own projects, and longer ones. The path is only as quick to build as the foundations under it.
The hard part is that the first golden path has no momentum behind it. There’s no catalogue of existing paths, no culture of reaching for the paved road first, no track record that makes developers trust it. You’re asking a team to change how they work on the promise that your way is better, and the only evidence you have is your own confidence.
So the first golden path is not really an infrastructure project. It’s an adoption project that happens to involve some infrastructure. Plan it that way and you’ll succeed. Plan it as “build the platform, developers will come” and you’ll join the long list of platform teams that shipped a portal nobody opens.
Picking the first path
Pick the path that is high-frequency, high-pain, and low-controversy. You want something developers do often enough that the savings compound, painful enough that they’ll thank you, and uncontroversial enough that you’re not fighting an architecture war on day one.
In practice the answer is almost always “create and deploy a new service”, because it’s the densest bundle of repeated decisions in any engineering org. But resist the urge to guess. Spend a few days doing the least glamorous research in platform engineering:
- Read the last three months of infra and access-request tickets. The pattern is right there. The same five requests, filed by different people, answered by the same overworked person.
- Ask three developers to walk you through standing up something new. Watch where they copy-paste from an old repo, where they Slack someone, where they say “I never remember how this works”.
- Find the thing with the worst ratio of frequency to documentation. Done weekly, documented nowhere, owned by tribal knowledge. That’s your path.
The test from the pillar still applies: can a new engineer ship a “hello world” version of this thing to production in a day, using only docs? If the honest answer is “no, they’d have to ask someone”, you’ve found a path worth paving.
What actually goes in it
A first golden path for “new service” is smaller than people expect. Resist scope creep ferociously. The minimum viable paved road is:
- A template repository. Not a 40-file scaffold. A working, deployable, hello-world service in your default language, with the project structure, the linter config, the test setup, and a README that’s true on day one.
git clone, change a name, and you have something that runs. - A default pipeline that comes for free. The template ships with CI/CD already wired: build, test, scan, deploy to a non-prod environment, promote to prod behind a gate. The developer doesn’t author a pipeline. They inherit one. Custom pipelines remain possible and remain the exception.
- Observability wired in, not bolted on. Metrics, structured logs, and traces are in the template from the first commit. The service shows up on a dashboard before it does anything useful. This is the single highest-leverage default you can ship, because the alternative is every team reinventing it later, badly. (If you’re not sure what “wired in” should actually emit, that’s a whole topic of its own - I wrote about the difference between dashboards and real observability.)
- Sane, opinionated defaults. Secrets from the secret store, not the env file checked into Git. The approved base image. The standard healthcheck endpoint. Resource requests that aren’t a wild guess. Every default you set is a decision a developer never has to make and never has to get wrong.
- A visible escape hatch. Document, on day one, how to do the thing the path doesn’t support. The escape hatch is what makes the path a road instead of a cage, and counter-intuitively it increases adoption, because developers trust a tool that admits its own limits.
Notice what’s not on that list. A developer portal. A service catalogue UI. A custom CLI with its own plugin system. Backstage. Those are all reasonable things to want, and they are all things you earn after you have three or four paths worth cataloguing. Building the catalogue before you have anything to put in it is the most common way the first six months evaporate. The portal is the index of your paved roads; you don’t write the index before the book.
Keep the path itself boring on purpose. The whole point of a paved road is that it behaves the same way every time, which means it should be built from components you understand completely. This is the boring stack argument applied to platform work: the golden path is exactly the wrong place to try the exciting new tool. Consistency is the feature.
The adoption problem
You’ve built it. Now comes the part the roadmap didn’t mention.
Find one design partner, not ten customers. Pick a single team - ideally one that’s about to start a new service anyway, so the path is the cheapest option in front of them rather than a migration. Sit with them. Watch them use it. Every place they get confused, get stuck, or fall back to the old way is a bug, and it’s your bug, not theirs.
Fix the friction in hours, not sprints. During the first adoption, your job is to make the path feel magical, which means a turnaround on friction measured in hours. The first team’s experience becomes the story every other team hears. If that story is “it was rough but the platform folks fixed things fast”, you win. If it’s “I tried it, it was broken, I went back to copy-pasting”, you’ve poisoned the well for a year.
Make the path the path of least resistance, then get out of the way. Adoption is not a mandate from an architecture review board. It’s the moment a developer who has never heard your pitch clones the template because it’s simply the fastest way to get to production, and it works. You’re not selling a platform. You’re removing the reasons not to use one.
Then tell the story. When the design-partner team ships their service in a day instead of a week, that number is your entire marketing department. Not the architecture diagram. Not the tech stack. The time-to-first-deploy, in the words of a developer who isn’t on your team.
How you’ll know it worked
The headline metric for a first golden path is time from “I want a new service” to “it’s running in production”. If that drops from days-with-a-side-of-tickets to a couple of hours - without anyone skipping a safety step to get there - the path is working, and you can say so with a number.
Underneath that, the same DORA metrics that measure platform work generally should start to move for teams on the path: deployment frequency tends to go up because shipping is cheap, lead time tends to drop because the pipeline is already there, and change failure rate usually improves because the path bakes in the safety rails individuals used to skip. The caveat matters - a path that’s really a compliance gate in disguise can move these numbers the wrong way, and when it does, that’s a signal the path needs fixing, not the developers.
And watch one qualitative signal that no dashboard captures: do developers reach for the path without being told to? The first time someone adopts it because a teammate mentioned it in standup, not because you evangelised it, you have a platform. Before that, you have a project.
When you shouldn’t build one yet
Honesty compels the off-ramp, because golden paths are not free and not always the answer.
If you have three engineers and four services, you don’t need a golden path. You need a shared README and a shared opinion, and you can hold both in your heads. Paving a road that two people walk is busywork dressed up as platform engineering. The discipline of building for the org you have rather than the one you imagine is the same one I argued for about Kubernetes: the abstraction has to be cheaper than the problem it’s hiding, and at small scale it usually isn’t.
You start earning a golden path when the same setup decisions are being made by enough different people, often enough, that the inconsistency itself becomes the problem. That’s typically somewhere past a couple of dozen engineers, or when you can feel the cost of every team doing the boring parts their own way. Until then, the paved road is a solution looking for the scale that justifies it.
The bottom line
A platform is not a portal, a roadmap, or a stack. It’s a collection of paved roads that make the right thing the easy thing, and you build it one road at a time. The first one is the hardest, not because the technology is difficult, but because it has to earn trust from nothing.
So pick the most-repeated, most-painful, least-controversial thing your developers do. Pave it end to end - template, pipeline, observability, defaults, escape hatch - and keep it ruthlessly small and ruthlessly boring. Get one team to use it, make their experience excellent, and let the time-to-first-deploy tell the story. Everything else - the portal, the catalogue, the second and third paths - is downstream of getting that one right.
If you’re trying to figure out which path to pave first, or you’ve got a platform that’s all portal and no road, let’s talk.