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.

We treat a platform like anything else we build: it has to survive checking. For an internal platform, the thing you can actually check is adoption. Whether teams pick it up depends on the engineering choices below. Get one wrong and it tends to show up months later as slow releases or an audit finding.

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.

For a business owner, those shadow scripts are where the risk sits. Nobody patches them, nobody scans them, and the person who wrote them may have left. The platform report still says everything is covered, so the gap only shows up when something breaks or an auditor asks how a service got to production.

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.

# 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

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.

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.

We build web platforms the way we'd want to use them ourselves. Usually that means one scaffold that does the whole setup and a pipeline that's quicker than anyone's homemade script. Then we keep template fixes flowing to services that are already live. If you want a second opinion on whether your teams would still choose your platform, start with an assessment. Our web development team does this work.