Platform engineering is the discipline of building the internal product that lets the rest of the company ship. Done well it is the difference between a 50-person engineering function that moves like a 200-person one — and the inverse. We design, build and operate platform teams that treat their developers as customers.
The shift in our industry over the past five years has been from "DevOps is everyone's job" to "platform is a product". We have been on both sides of that shift; the second version delivers, the first sounded good in conference talks and stalled in practice.
What an internal platform actually does
It removes the choices product engineers should not have to make. Where does my code run, how does it get deployed, how do I add a database, how do I emit logs, how do I roll back. Each of those should have a default that is fast, safe and well-documented — what the industry now calls a golden path.
A useful internal platform is also opinionated about what it does not do. The platform team's job is not to satisfy every team's preferred toolchain; it is to make the boring 80% so easy that product teams choose it voluntarily and reserve their custom work for things that genuinely warrant it.
How we work
- Developer-experience research first — interview the customers (the product engineers) before building anything.
- Golden paths for the two or three most common workloads, with paved-road tooling and out-of-the-box observability.
- An internal developer portal (IDP) — software catalogue, scorecards, templates and self-service in one place.
- Platform-as-a-product operating model — backlog, on-call, SLOs and a roadmap product teams can influence.
- Cost transparency — every service has a cost attribution and an owner who sees the bill.
Where we start
Most engagements begin with a developer-experience audit — what slows product teams down today, what they have built around the platform to compensate, and where the biggest wins are. The audit takes two to three weeks; the operating-model and team design follow from it. Build comes after.
We make a point of measuring the diagnostic against actual delivery metrics — lead time, change failure rate, time to recovery, deployment frequency — rather than against developer satisfaction surveys alone. Both matter; one is much easier to game.
Common building blocks
- Kubernetes or PaaS substrate with sensible defaults
- Pipelines, signing and policy gates baked into the golden path
- Service catalogue and templates (Backstage or equivalent)
- Telemetry, tracing and SLO tooling out of the box
- Secrets, identity and access primitives that work the same everywhere
- Cost attribution and quota management
None of these is a substitute for the operating model. The platform team has to be staffed and budgeted as a product team, with a roadmap, on-call, and skin in the SLOs the rest of the engineering organisation depends on. We help design and recruit those teams alongside the technical build.