Review this golden path. A new service starts with a portal form of 34 required fields; an architecture reviewer approves it within two days; the generator then creates a repository with build and deploy wired in. It does not create the database, the DNS record or the on-call rota, which are three tickets taking four to nine days. In the last year 18 of 60 new services went through it. What would you remove, what would you change, and what would you leave alone?

What is actually required

Strip it to the obligations somebody can name: the service must be identifiable and owned, it must be deployable by a pipeline nobody has to invent, and it must be reachable and observable in production. Everything else in those 34 fields is either derivable, deferrable, or someone's preference recorded as a requirement.

The diagnostic number is not the 30% adoption figure; it is where the other 42 services left the path. A path that covers eight of eleven steps does not deliver 73% of the value. The three missing steps are on the critical path to a running service, so 100% of journeys leave the path anyway — and a team that has already opened three tickets and written its own Terraform has no reason to come back for the part the platform does cover.

What I would remove

• Most of the form. Anything derivable is not a question: language and runtime come from the template choice, the cost centre from the owning team, environment names and quotas from the tier. Aim for four to six answers, and let a pull request against generated defaults handle the rest.
• The two-day approval, for the default case. Approval that asks about region, encryption and tagging is a policy check pretending to be a conversation. Encode it as an admission check that fails closed, and keep human review for the cases the check cannot decide.

The one change that matters

Extend the path across the three uncovered steps before improving any step it already covers. The database, the DNS record and the rota entry become part of the same generated change, provisioned by the same declarative resources the platform already reconciles. The target is a single artefact — one pull request — that takes a service from nothing to serving traffic, with time-to-first-request measured and published.

Then instrument the path itself: count journeys that start and the step each one abandons. A step where a third of journeys stop is the roadmap. Without that number a platform team optimises what it can see, which is usually the generator, not the ticket queue behind it.

What I would leave alone even though it looks odd

The generator itself, and its habit of writing files into the team's repository rather than hiding them. Generated-and-owned code is unfashionable next to an inherited platform library, and it is the right default here: teams can read it, debug it at three in the morning, and diverge when they need to. Keep the ownership record too, even though it is the one field nobody wants to fill in, because a service with no owner is the failure mode that costs the most later.

Common weak answers

• "Mandate the golden path." Mandating a path that does not reach production converts a coverage problem into a compliance problem, and the tickets remain.
• "Rebuild the portal with better UX." The form is not the obstacle; the four-to-nine-day tail behind it is. Polishing the covered steps is the most common way a platform team spends a year without changing adoption.
• "Raise adoption targets to 80%." A target is not a mechanism. The honest sequence is: measure where journeys leave, cover the earliest exit, then ask whether anyone still leaves.