Platform Engineering in Practice 2026: Golden Paths, Portals, and Proof Anyone Uses Them

> TL;DR: Platform engineering succeeds or fails on one question — will anyone actually use it? In practice that means: build golden paths (opinionated, end-to-end routes from idea to production) instead of handing out raw infrastructure, treat the portal as the shop window rather than the shop, run the platform as a product with internal customers who can say no, and measure adoption and lead time instead of counting what you built. Start with one thinnest viable platform for one real team, and let demand — not a roadmap deck — pull the next feature.

When I moved from DevOps engineering into project management, my core question changed. As an engineer it was "is it built right?" As a PM it became "will anyone actually use it?" I didn't expect that second question to be a platform engineering question — but it is the platform engineering question, asked verbatim.

Every failed internal platform I've seen described (and every post-mortem the community shares) fails the same way: a talented infrastructure team builds something technically excellent — a beautiful self-service portal, a pristine Kubernetes estate, immaculate Terraform modules — and the product teams keep opening tickets, running their own shadow pipelines, or quietly deploying around it. The platform was built right. Nobody used it. Our earlier piece on the rise of platform engineering covered why the movement exists; this one is about the operating discipline that makes it work in practice.

"Golden path" and "paved road" get used loosely, so let's be concrete. A golden path is an opinionated, supported, end-to-end route for one common job — the canonical example being "a new backend service, production-ready":

• A service template/scaffold: repo created with the standard layout, CODEOWNERS, and a README that isn't empty.
• CI already wired: build, test, image scan, deploy stages — the reusable-workflow pattern, not a blank workflow file and good wishes.
• Delivery already wired: a GitOps-managed deployment (in our world, Argo CD — see the tutorial) into the standard namespaces, with requests/limits defaults from the requests and limits guide.
• The un-fun parts included: TLS, ingress, dashboards, alert routes, a runbook stub, cost labels. The things every team needs and no team wants to rediscover.

Two properties make it a *path* rather than a template dump. First, it's supported: a named team owns it, fixes it, and answers questions about it. Second, it's optional in principle: teams may leave the path — and own everything the path would have given them. That combination (attractive enough to choose, honest about the trade) is what separates a golden path from a mandate wearing a friendlier name. Mandates produce compliance theatre; paths produce adoption metrics you can believe.

Backstage is the name everyone knows, and developer portals absolutely have their place: a service catalog, one searchable home for docs and ownership, a front door for scaffolding. But the portal-first project is the most common platform failure of the last few years. The pattern: six months building the portal, a launch announcement, and then the discovery that the underlying capabilities — provisioning, deployment, secrets, environments — are still ticket queues wearing a web form.

The working order is the reverse:

1. Capabilities first. Can a team actually create a compliant environment, deploy, and get credentials without a human in the middle? If not, no interface fixes that.
2. Interfaces second. CLI, GitOps repo, API, portal — in whatever order your users actually pull. Many healthy platforms run for years on templates + docs + a catalog page before a full portal earns its keep.
3. The portal when it pays. When discoverability becomes the bottleneck — hundreds of services, new hires drowning — the portal consolidates what already works. It amplifies a platform; it cannot substitute for one.

A useful test: if your portal went down for a day, would teams be inconvenienced or blocked? Inconvenienced means the platform is real and the portal is its window. Blocked means you built a very expensive single point of failure.

The Team Topologies framing popularised the idea of the Thinnest Viable Platform: the smallest platform that meaningfully accelerates the stream-aligned teams — and no bigger. The discipline behind the phrase is pure product management:

• Internal customers, real interviews. Before building, sit with two or three product teams. Where do they actually lose time — provisioning, flaky environments, deploy approvals, observability setup? Rank by their pain, not by your curiosity. (This is the PM question again: the backlog is theirs, not yours.)
• A roadmap measured in outcomes. "Ship Backstage" is an output. "New service to production in under a day, without a ticket" is an outcome. Roadmaps written in outcomes survive contact with reality; output roadmaps produce demo-ware.
• Adoption is the metric that can't be gamed. Percentage of services on the golden path, lead time from first commit to production for path users vs. off-path, ticket volume for things the platform now self-serves, and the quietest, most honest signal of all: do teams recommend it to each other? Anything you count, also ask whether the number would move if the platform got *worse* — if not, it's a vanity metric.
• Support is a feature. Office hours, a Slack channel with a response norm, docs written for the reader's deadline rather than the author's completeness. Platforms die of unanswered questions more often than of missing features.

For a team starting from zero, a realistic first iteration looks like this — scoped for one pilot team with one common service shape:

• Week 1 — pick the slice with the pilot team. Interview them, watch their current path to production, and write down every step that is waiting, copying, or asking. Choose the one service archetype they ship most (usually a stateless HTTP service) and define "done": scaffold → merged → deployed to production, no tickets.
• Week 2 — build the scaffold. Repo template with CI wired (reusable workflows), a Helm chart or kustomize base with sane defaults, Argo CD application manifest, dashboard and alert stubs. Ugly is fine; manual steps inside the template's README get listed as known debt, not hidden.
• Week 3 — the pilot team ships something real on it. Sit with them (pair, don't present). Every friction point they hit is your backlog, in their priority order. Expect the path to be wrong in at least three places — that's the pilot working as intended.
• Week 4 — harden the top frictions, write the docs from the pilot's notes, and invite team two. Not an org-wide launch: a second volunteer team. Volunteers are the adoption metric that predicts the rest.

Resist two expansions during this month: a portal (see above) and a second archetype. Depth on one path beats breadth across five half-paths, every time.

A golden path that fits 100% of cases is a fantasy; one that fits 80% and handles the other 20% gracefully is a platform. Design the off-ramps deliberately:

• Documented deviations. "Need a non-standard database? Here's the pattern, here's what you now own (backups, upgrades, on-call), here's who to tell." The cost of leaving the path should be explicit and paid consciously, not discovered during an audit.
• Extension points in the templates. Values files, overlays, and workflow inputs that let teams tune the common knobs without forking the whole scaffold. Forks are where platform improvements go to die — every fork is a team that stops receiving your fixes.
• A feedback loop with teeth. Deviations are product research: if five teams all deviate the same way, the path is wrong, not the teams. Review deviation patterns quarterly and promote the common ones into the path.

This is also where the cognitive-load argument lands honestly: the goal was never to remove all infrastructure thinking from product teams — it's to remove the *undifferentiated* infrastructure thinking, so their attention goes to the parts that are genuinely theirs.

AI tooling slots into a platform the same way it slots into DevOps generally — as an accelerator on the path, not a replacement for it (the full picture is in our AI for DevOps guide). Practical fits: generating first drafts of runbooks and docs from the templates, summarising incidents for the platform's users, and helping scaffold consumers customise the last 10% of a template. The trap is an "AI portal" that generates arbitrary infrastructure — it produces the opposite of a golden path: a thousand unique snowflakes, each confidently generated and none of them supported. The path stays opinionated; AI helps people walk it faster.

Platform teams rarely fail on technology. The recurring shapes:

1. The ticket team with a new name. The "platform team" still spends its weeks processing provisioning tickets by hand. If the work didn't become self-service, the rebrand was the deliverable.
2. Ivory-tower architecture. Standards designed without the pilot-team loop, announced as mandates, measured by compliance instead of adoption. Teams route around them within a quarter — usually silently.
3. Building for the demo. Optimising the launch presentation (portal screenshots, feature lists) instead of the second team's onboarding. Demos end; onboarding is forever.
4. Platform as a cost-cutting weapon. The moment teams believe the platform exists to justify headcount reduction, trust — the actual currency of adoption — is spent. Platforms are leverage, and leverage arguments only work when the lever's users believe it too.
5. No migration story. A great new path that requires teams to re-platform in a flag week will be adopted in never. Provide the incremental route: new services on the path now, existing services adopt piece by piece (CI first, delivery second, observability third).

1. Counting what you built instead of who uses it. Launch metrics belong to marketing. Adoption, lead time, and ticket deflection belong to platforms.
2. Treating docs as the last step. Undocumented self-service is a rumour. The docs are part of the path — write them from the pilot's notes, in week 4, not "when things settle."
3. Forgetting the off-path teams. The 20% with legitimate special cases are your harshest critics or your best case studies. Support their deviations visibly and they defend the platform in rooms you're not in.
4. Letting the platform team's own on-call rot. If the path breaks and nobody is paged, every team learns the same lesson: the path is not really supported. Reliability of the platform is the platform's first SLO.
5. Scaling the team before the demand. A three-person platform team serving five teams can be exactly right. Growing the platform org ahead of adoption just raises the ROI bar the platform must clear to survive its next budget review.

How big should a platform team be? As small as possible while owning the path end-to-end — often two to four engineers for the first golden paths. The binding constraint is scope, not headcount: one well-supported archetype per small team beats a large team spread across a portal, three archetypes, and a migration.

Backstage or build our own portal? Start from the test in this article: capabilities first. If provisioning and deployment are already self-service and discoverability is the pain, Backstage (or a commercial IDP) consolidates them well. If the capabilities are still tickets, a portal of any origin is a prettier queue.

How do we convince leadership it's working? Report the product metrics: adoption share, lead-time change for path users, self-service rate for the top former ticket types, and team satisfaction from a two-question quarterly survey. "We launched features" convinces nobody twice; "a new service reaches production in a day and 70% of teams choose the path" is a renewal argument.

Platform engineering vs. DevOps vs. SRE — who owns what? In practice: the platform team owns the paved road (templates, self-service capabilities, the catalog), SRE owns reliability outcomes and the practices around them, and "DevOps" is the culture both operate in — product teams owning what they run, with the platform making that ownership cheap. Titles vary; the seams above are the ones that work. Our DevSecOps checklist shows how the security layer weaves through the same path.

Can a small company do platform engineering? Yes — at small scale the "platform" might be one engineer's 20% time maintaining templates and a deploy pipeline for five teams. The product discipline (thin, adopted, supported) matters more than the org chart. What small companies can't afford is the big-bang version: a dedicated team building a portal nobody asked for.

Platform engineering in practice is product management applied to internal infrastructure. The technology — Kubernetes, GitOps, portals, templates — is the visible tenth. The other nine-tenths are the PM questions: Who is this for? What pain does it remove? Will anyone actually use it — and how will we know? Build one thin, supported, genuinely optional golden path for one real team; measure adoption like your budget depends on it, because it does; and let the teams who walk the path pull its next features into existence. That's the whole discipline — the rest is implementation detail, and the monorepo CI guide is a good example of what one of those details looks like when it's done as a platform would do it.