Platform Engineering Without the Hype

Every few years the industry renames its pain. Orchestration became SRE, configuration became GitOps, and somewhere around last year "we have too many YAML files" became platform engineering. I've now helped stand up two internal platforms — one that worked and one that quietly died — so let me separate the durable idea from the conference-talk version.

The actual idea

Platform engineering is building a paved road so product teams stop hand-rolling the same infrastructure. Instead of every squad writing its own Dockerfile, CI workflow, Helm chart, and deployment pipeline, the platform team ships a golden path: a template, a CLI, a portal button — and the paved road handles the boring 80%.

The metric that matters isn't "platform adopted." It's time from repo created to first deploy in production. At one place I worked it was six weeks; the platform brought it to one afternoon. That's the whole pitch: fewer tickets, less drift, faster humans.

The portal is the least important part

You will be tempted to install Backstage on day one. It's impressive — service catalogs, API docs, scorecards all in one view. It's also a Node service with a plugin ecosystem you'll be maintaining forever.

Start smaller. A portal solves discoverability: who owns this service, what's its repo, is it healthy. If your team can answer those questions from a README and a shared spreadsheet, you don't need a portal yet. What you need first is the golden path itself:

text

repo-template/
├── Dockerfile           # multi-stage, non-root, pinned base
├── .github/workflows/   # build, test, scan, deploy-staging
├── deploy/              # Kustomize base + one overlay per env
├── Makefile             # make run | test | deploy
└── README.md            # the paved road, explained in 20 lines

One gh repo create --template ... and the team has CI, scanning, and deploys wired. Copy-paste templates beat a $30k portal installation for teams under about 50 engineers.

What I'd build in order

Phase 1 — templates and pipelines. Repo templates, a shared CI library, one deploy mechanism everyone uses. No new UI. Measure time-to-first-deploy.

Phase 2 — self-service environments. Ephemeral preview environments per PR, or a make env command that provisions a namespace. This is where ticket queues actually start shrinking.

Phase 3 — the portal. Once you have services to catalog and a scorecard worth scoring (is it deployed? does it have an owner? is it in the golden path?), a Backstage or hosted IDP earns its keep. Skip it earlier and you get a fancy index of two repos.

Phase 4 — golden paths as code. Scorecards that gently enforce the path: production services must have on-call rotation, SLOs, and a runbook link. Gently — the moment the platform says "no," teams route around it, and you've built the thing you swore you wouldn't: the blocker.

The failure mode I lived through

My dead platform had 40% adoption and a beautiful portal. Why? Because we built it for developers instead of with them, and because our golden path only supported one stack. The Java team was happy; the Python and Go teams maintained private forks of everything, which meant we now had three ways to deploy instead of one.

The working platform had a different habit: a public roadmap, office hours, and a rule that no platform feature ships without two pilot teams using it in anger. The platform team's backlog came from developer interviews, not from conference talks.

When not to bother

Under ~10 engineers: a good template and one senior who knows the infra beats a platform team. You'd be building a product for five customers.
When the pain is process, not tooling: if deploys are slow because of a manual approval chain, no portal fixes that. Fix the policy first.
When leadership wants it as a rebrand: if "platform team" means the old ops team with new stickers and no mandate to change how work flows, it will die the same death, just more expensively.

The honest summary

Platform engineering survives contact with reality when it's treated as a product with users, a roadmap, and adoption metrics — not as a tooling shopping spree. Build the paved road, keep it short, measure how fast people go from zero to production, and add the portal only when the road has enough destinations to signpost.

The hype will move on. The teams that quietly cut their deploy time from days to minutes won't notice — they'll be too busy shipping.