Building an internal developer platform without a big team

When people hear "internal developer platform", they picture something huge. A shiny portal, dozens of integrations, a team of twenty, a year-long roadmap. No wonder smaller companies think it isn't for them.

I think that picture is wrong. A platform isn't a portal. It's whatever makes it easy for developers to get their code into production safely, without opening a ticket. That can start very small.

What a platform actually is (and isn't)

An internal developer platform is a set of tools, templates and automation that lets developers serve themselves. Typical building blocks:

• A way to create new services from a template, with a repo, pipeline and basic config already wired up.
• CI/CD that works the same way for every service.
• Environments that can be created and destroyed without asking anyone.
• Observability that is on by default: logs, metrics and traces without extra work.
• A catalog that answers "who owns this service, and where does it run?"

What a platform isn't: a tool you install. Buying Backstage or any other portal doesn't give you a platform, just like buying a gym membership doesn't make you fit.

The smallest platform that's still useful

If I had to start from zero with a small team, I'd begin with one thing: a golden path for the most common type of service in the company.

Say most of your services are small HTTP APIs in one language. The golden path could be:

1. A repository template with the code skeleton, a Dockerfile and a health endpoint.
2. A shared pipeline that builds, tests, scans and deploys it.
3. A Helm chart or Kustomize base with sane defaults for resources, probes and security.
4. Dashboards and alerts that appear automatically when the service is deployed.

That's it. No portal yet. A developer runs one command or clicks "use this template" on GitHub, and twenty minutes later their service is running in a test environment with monitoring.

A platform is successful when developers choose it because it's easier, not because they're forced to.

Build or buy: Backstage, Port and friends

Once the golden path works and you have more than one, a portal starts to make sense. It gives the templates a home and adds a catalog.

• Backstage is open source and very flexible. It's also real software you have to run, upgrade and extend, often with TypeScript.
• Port, Cortex, OpsLevel and others are SaaS. Faster to start, less control, monthly bill.
• A simple wiki page plus GitHub templates is a perfectly fine first version. Seriously.

My rule: don't introduce a portal until you have something worth putting in it.

How I'd measure if anyone uses it

A platform is a product, and products need feedback. A few numbers I'd track:

• Time to first deploy for a new service. Days becoming minutes is the headline win.
• Adoption: how many services use the golden path versus custom setups.
• Tickets to the ops team for routine requests. This should drop.
• Developer satisfaction: a short survey every quarter. Ask what's annoying, not just what's good.

And talk to developers. Sit with someone while they create a new service. Every place they hesitate or ask a question is a bug in your platform.

What I'd tell someone starting today

Start with the most painful, most frequent task. Automate that properly. Make it so good that people ask for more. Then pick the next thing.

Don't try to cover every edge case. Keep an escape hatch so teams with unusual needs can still do their own thing. A platform that blocks people becomes the new wall DevOps was supposed to tear down.

So, can a small team do it?

Yes. A small team can't build everything, but it doesn't need to. One golden path that really works beats a portal full of half-finished features.

My take: start with one road, pave it well, and let people's footsteps tell you where to build the next one.

— Desly