Before product-market fit, a team has one real job: to find out what people want. Infrastructure is whatever gets the next experiment out. A deploy script one person understands, environments set up by hand, monitoring added after the first outage. At that stage it is the right trade.
After fit, the same habits start to cost. More engineers join, one service becomes several, customers ask about uptime and security, and each team solves the same problems in its own way. Platform engineering is the answer many growing companies reach for. This post explains what it is, what an internal developer platform contains, how to tell whether it is working, and how to build one in small steps.
Why it hurts after product-market fit and not before
With five engineers in one room, knowledge travels by conversation. Everybody knows how a release works because everybody has done one. With thirty engineers in six teams that stops being true, and the symptoms are familiar:
- A new engineer needs weeks before a first change reaches production. Most of that time goes on access, setup and finding out who knows what.
- Every service is deployed a little differently, so moving between teams means learning again.
- A few people hold the infrastructure together, and every team waits in their queue.
- Security and compliance questions arrive at the end, as a review that blocks a release.
- Incidents take long to diagnose, because each service logs and reports in its own way.
None of this is a failure of the people involved. It is what happens when the number of teams grows and the way of working stays the one that suited a single team. The cost is paid in engineers' attention. Time that should go to the product goes to plumbing, and the same plumbing is built several times.
What platform engineering is
Platform engineering treats the tools and infrastructure that engineers use as a product, with the company's own developers as its customers. A small team builds and maintains a set of self-service capabilities, so that product teams can create, ship and run software without filing a ticket and waiting.
It grew out of DevOps and does not replace it. "You build it, you run it" works well until every team is expected to be expert in cloud networking, pipelines, secrets and monitoring on top of its own domain. A platform leaves the ownership with the product team and takes away the need to assemble everything from parts.
The word "product" matters. A platform nobody asked for, delivered as a mandate, is used reluctantly and worked around. One that is built from the teams' real problems is adopted because it is the easiest way to get the job done.
What an internal developer platform contains
The contents vary, but most platforms cover the same ground:
- Service templates. A new service starts from a template with the build, tests, deployment, logging and health checks already wired, so the first day's work goes into the feature.
- Environments on demand. Development, preview and staging environments created from a definition in code, close enough to production that results can be trusted.
- A standard delivery pipeline. One route from a merged change to production, with the same stages for every service.
- Infrastructure as code. Databases, queues and storage requested through reviewed definitions, with sensible defaults.
- Secrets and access. One place for credentials, and one way to grant and remove access.
- Observability. Logs, metrics and traces collected the same way everywhere, with dashboards and alerts that exist from the first deployment.
- A catalogue. A list of services with their owners, documentation, dependencies and state.
A portal with a friendly interface can sit on top, but it is the last thing to build. The value is in the capabilities and in their being consistent.
The paved road
The idea that holds a platform together is the paved road, sometimes called the golden path: one well-kept, well-documented way to do each common thing. Take it, and deployment, monitoring and security come with it. You may leave it, and then you carry what you take on yourself.
That is different from a rule that forbids everything else. A team with an unusual need can still go its own way. The road only has to be so much easier that leaving it needs a reason.
Part of the gain is in engineers' heads. Every choice an engineer does not have to make about infrastructure is attention left for the product. Fewer ways of doing things also means fewer things to patch, document and teach.
Standard pipelines and built-in guardrails
When each team writes its own pipeline, each pipeline is a small product with its own bugs. Improvements made in one place do not reach the others, and an audit has to examine every one. A shared pipeline, used through a template with a few parameters, turns one fix into a fix for everybody.
Security benefits most. In many growing companies security is a review near the end: someone checks the change, finds problems, and the release waits. Guardrails move those checks into the road:
- Dependency and container scanning in every pipeline.
- Secret detection before a change merges.
- Access defined in code and reviewed like any other change.
- Policies checked automatically: encryption on, no public storage, required labels present.
- A log of who deployed what and when, produced as a side effect of deploying.
The result is the opposite of what people expect from security work. Releases get faster, because the checks run in minutes on every change and stop being a meeting. For a company that sells to regulated customers, the evidence an auditor asks for already exists.