Gatekeeping Vs. Golden Paths: Two Models of Platform EngineeringGatekeeping Vs. Golden Paths: Two Models of Platform Engineering

Every company has a platform team. Most of them are accidentally making developers slower.

Two ways of running that team dominate. In the gatekeeping model, the platform is a bottleneck: approvals, central ownership, "ask us first." In the golden path model, the platform offers opinionated, self-service paths that make the right thing the easiest thing. Gatekeeping feels safe but destroys velocity; golden paths achieve the same compliance goals while respecting developer autonomy. Here are both patterns, their tradeoffs, and how to move from one to the other. The goal is not to blame platform teams (many inherited or were handed a gatekeeping mandate) but to show a different model that works better.

The Gatekeeping Model

Many platform teams operate as gatekeepers. New services need an approval from an architecture board. Deployments run only through a mandatory set of Helm charts or a single blessed stack: anything else is "not supported." A vetting meeting where platform engineers reviews and approves (or rejects) other teams' plans before they can use a new technology or framework. To get a database or a queue, you open a ticket and wait until someone from platform provisions it. The pipeline might require a sign-off from security, then from SRE, then from the platform lead. Each gate is justified on its own; together they turn the platform into the thing that says no. The intent is reasonable: reduce risk, satisfy auditors, and keep the estate consistent. Velocity ends up depending on the platform team's capacity to say yes, and that capacity is finite.

Organizations fall into this pattern for understandable reasons. Risk aversion runs high after an incident or an audit. Compliance requirements push toward central control and paper trails. Cost is another factor: too often the platform team is there as a cost manager: their mandate is to reduce spend. Saying no to new infra, constraining choices, and delaying provisioning all help the budget; developer experience does not. When cost reduction is the priority, DX slips. And often there is a lack of trust in product engineers: the assumption that without strict guardrails, they will choose the wrong database, skip security steps, or create unmaintainable sprawl. So the platform adds process. More process feels like more safety.

The hidden costs emerge over time. Deployment frequency drops. What used to be a push becomes a request; what used to take an hour takes a week. Developers learn to route around the system. They spin up side projects in a cloud account that "doesn't count," or they avoid the platform entirely for anything that needs to move fast. Shadow IT proliferates, and the platform team has no visibility into it. The engineers who care most about shipping leave for teams or companies with less friction. The platform team, meanwhile, spends its time in meetings and ticket triage instead of building better defaults. The org wanted safety and consistency; it got a bottleneck and bypasses. Everyone loses.

The Golden Path Model

A golden path is an opinionated, paved road: the easiest way to do the right thing. The platform does not say "you must use this." It says "if you use this, you get speed and compliance by default." The path is so good that developers rarely want to leave it, but they can. Autonomy is preserved. Going off-path is allowed; it is simply not the default. That distinction matters. Mandating a single stack is still gatekeeping, just with fewer options. Golden paths compete on merit. When a team has a genuine reason to go off-path (e.g. a special runtime or an experiment), they can. Most of the time they won't, because the path is fast and well supported.

Compliance is baked into the path. Security defaults, audit logging, and approved patterns live inside the templates and pipelines. When a developer deploys via the golden path, they get the right networking, secrets handling, and observability without asking. The platform enforces through design, not through approval gates. Auditors still get their paper trail (every deploy is logged, every change is traceable), but the developer never has to wait for a human to click "approve." The path is compliant by default, so the platform does not need to gate the process.

note

Compliance lives in the path, not in the approval. When the default path is secure and auditable, you get both speed and control.

Familiar examples include Spotify-style golden paths (documented, supported routes for different app types), Backstage templates that generate compliant repos and CI from a single click, and Heroku- or Vercel-style push-to-deploy: you push, the platform builds and deploys with sensible defaults. No ticket, no meeting. The path is the policy. The platform invests in making that path excellent (good docs, fast feedback, sensible defaults), so choosing it is obvious. The platform team's job is to improve the path (better defaults, clearer docs, fewer steps), so more teams stay on it by choice.

I've built and operated a Vercel-inspired self-service PaaS in this spirit: opinionated paths, compliance in the defaults, no approval queue for the happy path. In future posts I'll walk through how we designed it and what we'd do differently. Until then, pick one use case, pave the path, and let your developers show you what they prefer.

A Side-by-Side Comparison

A single table makes the tradeoffs easy to scan. Here's how the two models compare across a few dimensions:

In practice, golden paths win on velocity and satisfaction without giving up compliance. The platform team's job shifts from saying no to making the yes path obvious and easy. That shift is cultural as much as technical: you measure success by adoption and time-to-deploy, not by the number of tickets closed.

How to Move From Gatekeeping to Golden Paths

You don't have to flip a switch. Start with one use case, for example deploying a stateless web app. Define the golden path: repo template, CI that builds and deploys, one command or one click to production. Build that path alongside the existing approval-based process. Don't rip out the old flow first. Let the new path exist as an option. Teams that are ready can switch; everyone else keeps the old flow until they see the benefit. Running both in parallel gives you a clear before-and-after: you can point to teams on the new path and show the difference in time to first deploy and deploy frequency.

Don't mandate. Make the path obviously better (faster, clearer, with less paperwork) and measure. Track time to first deploy, how many teams choose the path, and how often they deploy. Put the numbers in a dashboard or a simple report. Let adoption speak. When teams see that they can ship in minutes instead of waiting in a queue, they switch. Forcing the change from the top often backfires: it reinforces the idea that the platform is something done to developers, not for them.

Earn trust from leadership by showing both sides: compliance (audit trail, security defaults, consistency) and velocity (deploys per week, time to first deploy). One team’s success on the new path beats a dozen slides about "platform strategy." Bring numbers. "We cut time to first deploy from two weeks to under an hour" is more convincing than "developers like it." Use that evidence to expand to more use cases (databases, queues, background workers), one at a time. Each new path you add reduces the load on the approval queue and gives you another data point. Gradually, the golden path becomes the norm and the gatekeeping queue becomes the exception. The platform team's role shifts from approving requests to maintaining and improving the paths that developers already prefer (a better job than policing tickets).

tip

Start with one use case and one path. Let adoption prove the model before you expand.

---

The best platform is the one developers choose to use. Gatekeeping forces usage through process; golden paths earn it by being the path of least resistance. If your platform team spends most of its time in approvals and tickets, you are in the situation this article started with: a team that is accidentally making developers slower. Shifting to golden paths is a high-impact change. You keep the compliance and consistency that leadership cares about, and you give developers the speed they need. Nobody has to choose between safety and velocity.

---

• Platform Engineering
• DevOps
• Developer Experience