What platform engineering means at five

Platform engineering is the hottest job title in infrastructure right now. Gartner put it on the hype cycle, every conference has a track for it, and teams of six are hiring "platform engineers." Most of the writing about it assumes you have 50 engineers, three VPs of Engineering, and an internal developer portal. Here's what it actually means at five.

What platform engineering actually is

Platform engineering is the discipline of building and running the internal infrastructure that product teams use to ship software. Instead of every team solving DevOps problems from scratch, a platform team (or a platform practice) builds a shared foundation: deploy pipelines, observability, secrets management, service templates, developer tooling.

At Google or Spotify, that's a team of 40. At a five-person studio, it's a set of conventions, scripts, and shared config that everyone agrees to follow. The concept scales down — the machinery doesn't.

At five engineers

The problems platform engineering solves are real regardless of team size:

• How does a new engineer go from zero to running the service locally?
• How does a feature go from merged PR to production?
• How do we know the service is healthy?
• How do we manage secrets without emailing them in plaintext?

At five engineers, every hour spent answering "how do I deploy this?" is an hour not spent building. The platform is the answer to those questions, even if it's just a bash script and a wiki page.

The minimal platform

What a minimal but real platform looks like at a small team:

• A local dev script. One command to start all services, seed the database, and watch for changes. make dev or a Taskfile. Anyone can run it on a fresh laptop.
• A deploy script. One command or one CI job that goes from a tagged commit to a running deploy. See the boring deploy pipeline post.
• Service templates. A Git template or a script that generates a new service with the standard structure, CI config, Dockerfile, and observability wiring already in place. Nobody starts from scratch.
• Secrets management. Even at five engineers, secrets should not be in .env files checked into git. 1Password CLI, Doppler, or AWS Secrets Manager — pick one and standardise.
• A runbook.A living document that answers "what do I do when X is broken?" for the ten most common incidents. Maintained by the person who last fixed each one.

The golden path

The most useful concept from enterprise platform engineering that scales down to small teams is the golden path: an opinionated, well-maintained path that makes the right thing the easiest thing.

A golden path for a Go backend might be: service template → local dev script → CI with tests + lint → deploy to Fly.io or a VPS via a Makefile target → Grafana for observability. That's it. Every new service follows the same path. Engineers make product decisions, not infrastructure decisions.

# The whole golden path in four commands.
make new-service name=billing   # scaffold from template
make dev                        # local dev with hot reload
git push                        # CI runs tests + build
make deploy env=production      # tag + ship

When to invest more

The signals that your platform investment is insufficient:

• New engineers take more than a day to get running locally.
• Deploys require more than one person's knowledge.
• Engineers are solving the same infrastructure problem on different services independently.
• You've had two incidents where the fix was "we didn't know it was broken."

Any of those is a signal to spend a week on platform work before adding the next feature. The compound return on a fast, reliable developer experience is larger than any individual feature.