Platform engineering has a dirty secret: plenty of internal developer platforms are technically impressive and almost entirely unused. The portal is live, the templates exist, the docs are polished — and product teams keep copy-pasting a Terraform module from 2021 because it is what they know.
The fix is rarely more features. It is treating the platform as a product with customers, and designing golden paths — opinionated, supported routes to production — that are genuinely the path of least resistance.
Start with friction, not tooling
Before choosing Backstage, Port or a home-grown portal, spend two weeks measuring where developers lose time. Useful questions:
- How long does it take a new engineer to ship a change to production?
- How many tickets does it take to get a new service, database or queue?
- Which steps require waiting on another team?
- Where do incidents come from — config drift, missing alerts, manual changes?
The answers define your roadmap. If creating a new service takes three days and five tickets, your first golden path is obvious.
Anatomy of a good golden path
A golden path is not a template. A template is a starting point; a golden path is a supported lifecycle. For a new backend service it usually includes:
- Scaffolding — repository, CI pipeline, Dockerfile and Helm chart or Kustomize base generated in one step.
- Infrastructure — namespaces, IAM roles, databases and secrets provisioned through Terraform modules or Crossplane compositions, not tickets.
- Delivery — GitOps (ArgoCD or Flux) wired in from day one, with preview environments for pull requests.
- Operability — default dashboards, SLO-based alerts, structured logging and tracing already configured.
- Security — image scanning, policy checks and least-privilege identities enabled by default.
If a team uses the path, all of this just works. If they leave the path, they own the consequences — and that trade-off should be explicit.
Paved, not gated
The fastest way to kill adoption is to make the golden path mandatory before it is good. Developers route around gates. Instead:
- Make the paved road visibly faster than the alternative.
- Allow escape hatches — raw manifests, custom Terraform — with clear ownership boundaries.
- Use policy (OPA Gatekeeper or Kyverno) only for non-negotiables: no privileged pods, required labels, approved registries.
Abstractions: thin beats clever
A common failure is inventing a new configuration language that hides Kubernetes completely. It looks friendly until a team needs a feature the abstraction did not anticipate. Prefer thin abstractions that compose with the underlying tools:
# service.yaml – a thin, opinionated interface
name: payments-api
team: payments
runtime: java21
expose: internal
resources: medium
dependencies:
- postgres: payments-db
- queue: payments-eventsBehind it, generate standard manifests and Terraform that engineers can read, debug and, if needed, eject to.
Measure the platform like a product
Track a small set of outcome metrics, not vanity metrics:
- Lead time for changes and deployment frequency (DORA).
- Time to first production deploy for a new service.
- Percentage of services on the golden path.
- Developer satisfaction from a short quarterly survey.
If adoption stalls, interview the teams who opted out. Their reasons are your backlog.
Staff it like a product team
A platform team needs a product owner (even part-time), a public roadmap, release notes and office hours. Version your templates, publish upgrade guides and automate migrations where possible — a golden path that rots after six months is worse than none.
The takeaway
An internal developer platform succeeds when developers would be annoyed if you took it away. Start from measured friction, ship one golden path end to end, keep abstractions thin and earn adoption instead of mandating it. Tooling is the easy part; product thinking is the hard part.
