Platform as a product: self-service and golden paths

Run the platform as a product: know its users, find the requests that wait on the platform team, turn them into golden paths and self-service flows, replace manual approvals with guard-rails, and measure whether developers' lives actually got better.

Users, not tickets

A platform team builds a product for internal users: application developers, data teams, SREs. Treat it that way: know who they are, what they're trying to do, where they get stuck, and whether the platform helps.

Ways to find out: shadow a team onboarding a new service, read the last 100 tickets, run a short survey every quarter, and measure the time from "new idea" to "running in production".

A good platform is a self-service supermarket, not a shop where you queue at the counter and ask for each item. The shelves (golden paths) are well stocked and labelled, the checkout (pipeline) is quick, and security tags (guard-rails) stop anything leaving that shouldn't, without a guard checking every bag.

Find what to make self-service

List the requests that wait on the platform team, with volume and waiting time:

Request	Per month	Wait	Self-service version
New namespace + access	25	2 days	Pull request adding a team file; GitOps creates namespace, quota, RBAC
DNS name + certificate	15	1 day	Gateway route with a hostname; certificates issued automatically
New service skeleton	10	3 days	Template repository with CI, Dockerfile, manifests and dashboards
Secret for a cloud service	20	1 day	Workload identity binding declared next to the app

Start with the highest volume × wait.

Golden paths

A golden path covers a whole journey, not one tool:

Create a service from a template (code skeleton, Dockerfile, CI workflow, Kubernetes manifests, dashboards, alerts).
Push → CI builds, tests, scans and signs → GitOps deploys to dev.
Promote to staging and production by pull request.
Logs, metrics, traces and an SLO exist from day one.

Teams can leave the path when they truly need to; the platform supports the path first and the exceptions second. A developer portal (Backstage or similar) helps once there are several paths and many services; start with good templates and docs.

Guard-rails instead of gates

Replace human approvals with automated rules: admission policies (approved registries, limits required, no privileged pods), quotas, network policy defaults, cost budgets. Humans then review exceptions, not every change.

Documentation is part of the product

Short, task-based guides ("deploy your first service", "add a database", "debug a failing rollout"), kept next to the templates, tested by new joiners. If people ask the same question twice, the docs have a gap.

Measure it

Metric	Shows
Time to first production deploy for a new service	Onboarding friction
Tickets per team per month	Remaining manual work
Golden path adoption (% of services)	Whether the path is good enough
Developer satisfaction (quarterly, 3 questions)	Whether it feels better

Try it: one request, made self-service

Pick the most frequent request your team handles.
Write down every manual step and every approval in it today.
Design a pull-request-based flow with automated guard-rails that replaces it.
Build the smallest version (a template plus a GitOps folder) and run it with one friendly team.
Measure the waiting time before and after.

Going deeper: product habits

Keep a public backlog and changelog for the platform.
Hold office hours and treat recurring questions as product bugs.
Deprecate old paths deliberately: announce, migrate with help, then remove.

Recap

The platform is a product for internal users; learn their pains.
Self-serve the highest volume × wait requests first.
Golden paths cover the whole journey; docs are part of the product.
Guard-rails replace gates; humans review exceptions.
Measure onboarding time, tickets, adoption, satisfaction.

This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.