How do we avoid creating a new bottleneck in the platform team?

Keep the platform surface area small. Offer paved-road defaults and guardrails, not custom workflows. Publish an eject path and require teams that deviate to own on-call and costs. Use GitOps so deployments don’t route through platform engineers.

What if a team needs something the paved road doesn’t support (e.g., `Kafka` with custom networking)?

Let them deviate with an RFC. If it’s broadly useful, productize it into the template. Otherwise, they own the runbooks and SLOs. The thin waist (VCS → CI → registry → GitOps → runtime) ensures deviations don’t force a re-platform.

Is `ArgoCD` mandatory? Can we use `Flux`?

Pick one. `ArgoCD` and `Flux` both work. The point is GitOps with automated sync and auditable drift, not the specific logo. If you switch later, keep the same repository structure to minimize churn.

How do we measure success without gaming the numbers?

Use DORA metrics (lead time, deployment frequency, change failure rate, MTTR) from your VCS/CI/CD events, not self-reporting. Pair with cost per service and error budget burn. Publish a monthly scorecard in Backstage.

What size team do we need to run this?

We’ve run this with 3–5 platform engineers supporting 20–40 services. Focus on enablement, automation, and ruthless scope control. Add headcount only when SLOs slip or migrations back up.

Platform-productivity · Oct 3, 2025 · 9 minute read

Stop Building a Platform; Build a Paved Road: “Just-Enough” Patterns That Unblock Teams

If your platform feels like a toll booth, you’ve overbuilt it. Here’s the minimal, boring stack that lets product teams ship without filing tickets or learning your bespoke CLI.

Back to all posts

Stop Building a Platform; Build a Paved Road: “Just-Enough” Patterns That Unblock Teams

Key takeaways

Implementation checklist