Golden paths beat golden cages

Every internal platform claims to make developers faster. The honest test is brutal: if usage were optional, would anyone still use it? A golden pathdefinitionOn an internal platform, it's the supported, ready-made way to build and ship a service, designed to be the easiest correct option. gets traffic because it's the easiest correct way to ship. A golden cage gets traffic because someone mandated it, and a mandate is the most expensive way to hide that your platform lost the argument.

A platform, for us, is a claim like anything else we build, so it has to survive verification. For internal platforms the thing you can check is adoption. Whether you get it comes down to three engineering decisions.

Platform teams love to report coverage ("90% of services are on the platform") while the mandate behind the number does the real work. Mandated adoption tells you nothing, because the alternative was a policy violation. Worse, it breeds shadow platformsdefinitionTooling a team quietly runs itself, like private deploy scripts, because the sanctioned platform is too slow for them.. Think of the team that quietly runs its own deploy scripts because the sanctioned pipeline costs them a day per release. Measure what developers do when they have a choice instead. Voluntary onboarding rate is one. Time-to-first-deploy for a new service is another, and so is how often teams who left come back. Treat the platform as a product with internal customers who can churn. They can, and the ones who churn silently are the ones you learn nothing from.

Teams pick the paved road when the default path already bundles everything they'd otherwise assemble by hand. One scaffolddefinitionYou run a command or template and get a new project with the structure and standard setup already in place. Nobody on the team assembles it by hand. command should give them a repository with CI/CD wired and observability instrumented. Security scanning should be on, secrets management configured and an owner recorded in the service catalogdefinitionOne central list of every service an organization runs, with who owns it and how to reach them, including on-call.. Backstage-style software templates work well here. Leave compliance out of the pitch to delivery teams and talk about time. The platform route reaches production this afternoon. The artisanal route reaches it next month, pending four access tickets. Sensible defaults do the rest of the persuading. Structured logs and health endpoints should arrive without anyone asking, and so should dependency pinning.

The road also has to stay paved. A template that scaffolds beautifully and then abandons its services is a one-time gift, and a gift doesn't make a platform. Six months later every team is hand-patching the same CI upgrade the template already fixed for new arrivals. So treat scaffolded output as a managed surface. Automated pull requests roll template updates into existing repositories, and each service gets a scorecard showing where it has drifted from the current baseline. DriftdefinitionOlder services fall behind the current standard setup as templates improve and they don't get updated. Drift is that growing gap. you can see is a to-do list. Drift you can't see is next year's security finding.

# one command, production-shaped from minute one
$ platform create service --template api-service
  ci/cd: pipeline wired · deploy on merge
  observability: logs + traces + golden-signal alerts
  security: SAST · dependency scan · secrets vaulted
  catalog: owner registered · on-call linked
  escape hatch: documented · deviations owned by your team
✓ time-to-first-deploy: same day

Sooner or later a workload shows up that the platform wasn't designed for. Maybe the ML team needs GPUs the pipeline doesn't schedule. Maybe an edge service has latency budgets the standard runtime can't hit. A cage forbids leaving, while a path prices it. So make leaving through the escape hatchdefinitionAn approved route off the standard platform path, for a workload the platform can't serve. Whichever team leaves picks up the extra operational work itself. legal and visible, and owned. The team writes a short deviation record saying what they're doing differently and why, and they explicitly take over the operational burden the platform was absorbing. If you left the paved road, you carry your own pager. Then check periodically whether the reason still holds. Deviations stay in the open that way, and they double as a roadmap. Three teams escaping for the same reason is the platform's next feature, discovered for free.