Platform engineering content has a scale problem. The conference talks come from companies with 500 engineers and a 30-person platform org running a custom developer portal. Then a 20-developer company reads about it and asks me whether they need Backstage.

They don't. But they do need platform engineering, just not the version being marketed to them.

I run a four-person consultancy. Most of our clients have between five and fifty developers. Nobody in that range can afford a platform team, and nobody should try. What they can afford, and what they can't afford to skip, is a platform practice: a small set of paved roads that make the right way to ship also the easy way.

What the platform actually is at this scale

Strip away the vendor landscape and platform engineering is one sentence: reduce the number of decisions a developer has to make to ship safely. At Spotify scale that takes a portal. At 20 developers it takes four things, none of which is a product you buy:

1. A template repository

One repo that is the canonical starting point for a new service. Not a scaffolding CLI with forty prompts, just a repo you click "Use this template" on. It contains:

  • The Dockerfile that builds the way your infra expects (non-root user, health endpoint, sane signal handling).
  • The CI workflow, already wired.
  • The Helm chart or task definition or whatever your deploy unit is, with resource requests filled in with defensible defaults.
  • A README that says what to change and, more importantly, what not to.

At one client, before the template existed, every new service was a copy-paste of whichever existing service the developer liked best, including one that copied from a service whose CI had been broken for months. The template repo killed that whole failure class in an afternoon of work.

2. A shared CI library

Reusable GitHub Actions workflows (or Jenkins shared library, or GitLab includes; the mechanism doesn't matter). Every service calls build-test-scan-push from one place. When you need to add SBOM generation or rotate a registry credential, you change one file and every pipeline inherits it.

# each service's workflow shrinks to this
jobs:
  ci:
    uses: acme/platform-workflows/.github/workflows/service-ci.yaml@v3
    with:
      service-name: payments
    secrets: inherit

The alternative (thirty hand-rolled pipelines, each subtly different) is where CI goes to rot. I've audited estates where fixing one vulnerability scanner config meant 27 near-identical PRs. That's the tax you pay for skipping this.

3. One paved deploy path

Exactly one blessed way to get code to production. Merge to main → CI builds and pushes → GitOps or pipeline deploys → automated smoke check. Whatever the mechanics, the property that matters is there is one path and it's the default.

Not the only path, the one paved path. Which brings me to the distinction the whole discipline hinges on.

4. Docs that answer the first five questions

How do I create a service. How do I get logs. How do I add an env var / secret. How do I roll back. Who do I ask when it breaks. Five pages, kept honest. That's it. Nobody at this scale needs a docs portal; they need those five answers to not live in one senior engineer's head.

Golden paths, not golden cages

The paved road only works if you can leave it. A golden path says: stay on this and networking, TLS, deploys, and observability are handled for you; step off and you own what you touched. A golden cage says: you may not step off.

Cages fail at every scale, but they fail fastest at small scale, because the platform (you, on a Tuesday, between client calls) can't possibly anticipate every need. The team that genuinely needs a WebSocket service, or a GPU job, or a Postgres extension your template didn't imagine, will either be blocked (and resent the platform) or route around it in secret, and now you have shadow infrastructure that the paved road knows nothing about.

The rule I give clients: the platform earns adoption through being the easiest option, never through being mandated. If people are escaping your golden path, that's product feedback, not a compliance problem.

When NOT to build an internal developer platform

This is the conversation I have most often, because saying "no" to an IDP is half of my job some months. Skip the platform build-out when:

  • You have fewer than ~15 developers. Below that, the coordination cost you're eliminating doesn't exist yet. A template repo and a wiki page beat any portal.
  • You deploy one or two applications. Platforms amortize across services. Two services can't amortize anything.
  • Your deploy path isn't stable yet. Paving a road means committing to a route. If you're mid-migration from ECS to EKS, pave after you arrive, not during.
  • The pain you're solving is actually organizational. No portal fixes "the ops person is a bottleneck because management won't let developers touch prod." I've been brought in to "build a platform" three times where the real deliverable was that sentence, delivered to leadership.

The Backstage question

I get asked about Backstage on maybe half of new engagements, so let me be direct: for small teams, Backstage is a trap, not because it's bad software, but because it's a framework, not a product. You don't install Backstage; you adopt a React/TypeScript codebase and staff its maintenance forever. Spotify built it with a full team. The plugin ecosystem assumes you'll write plugins.

What small teams actually get from a Backstage adoption, in my experience watching two of them up close: three months of setup, a service catalog that's stale by month five because nobody owns updating it, and a scaffolder that does what a template repo did for free. One client had a beautiful Backstage instance and a #help-infra Slack channel; guess where developers actually went.

If you're under ~50 engineers and you want a catalog, a YAML file in a repo or even a spreadsheet answers "what services exist and who owns them" at 0.1% of the cost. Revisit when the spreadsheet genuinely stops scaling. That's a great problem to have, and by then you'll know exactly what you need from a portal.

The consultancy angle

When Nepheli takes on a platform engagement for a small company, the deliverable is deliberately boring: template repo, CI library, one paved deploy path, five docs pages, and the part that matters most: a handover where their own developers make the next change to the platform, not us. A platform a consultancy has to babysit is a failed engagement wearing a success costume.

Platform engineering without a platform team isn't a compromise. At small scale it's the correct architecture: maximum paved road, minimum standing infrastructure, zero portals. Do the four things. Skip the rest until it hurts.