Platform Engineering Without a Platform Team
The industry turned platform engineering into a hiring decision. It isn't. The minimum viable platform I run on Keaz across twelve services — no platform team — and when to finally hire one.
.jpg%3F2026-07-14T18%253A30%253A14.918Z&w=3840&q=100)
Platform engineering has quietly become an org-chart question. DORA's research found that by 2025, 90% of organizations were running an internal developer platform and 76% had a dedicated platform team, so the advice a founder now hears is that scaling means hiring one. I think that is the wrong lesson from the right data. A platform is not a team — it is a set of capabilities: a paved road to ship a service, self-service environments, the hard parts solved once, cheap failure, and clear feedback. A single senior engineer can install a minimum viable version of all five. I run twelve services on Keaz with no platform team, and this is the platform I actually built, mapped to DORA's own capability list — plus the three signals that say it is finally time to hire the team.
The distinction is the whole argument: an internal platform is the paved road your team ships on — the golden paths, self-service, and fast recovery that let developers deliver value without fighting infrastructure — and none of it requires a dedicated team to exist.
Why this matters now
The trigger is a shift in what founders are being told to worry about. In its 2026 report on the ROI of AI-assisted software development, Google Cloud's DORA team reached a blunt conclusion: the returns on AI come not from the tools but from the quality of the internal platform, the clarity of workflows, and the alignment of teams. Its platform-engineering guidance puts it in almost arithmetic terms — when platform quality is high, AI adoption's effect on organizational performance is strong and positive; when platform quality is low, the effect is negligible.
The same month I write this, a KubeCon Europe talk made the rounds arguing that a mature internal platform was never a single, unified platform but rather a set of capabilities. Read those together and the message to a small team is not go hire platform engineers. It is that the paved road now decides whether your AI spend ever reaches production — so build the road. The road and the team are not the same purchase.
The platform is five capabilities, not a headcount
Strip DORA's definition down and an internal platform does five things: it gives developers a golden path to build, test, and deploy; it lets them self-serve instead of filing tickets; it shifts down hard problems like Kubernetes, networking, and security into the platform so app teams do not each solve them; it makes failure cheap and recovery fast; and it gives clear feedback on the outcome of every task. None of those five is employ a platform team. They are engineering outcomes. A team is one way to produce them at large scale, across many tenants with competing needs; at small scale, they are things you build once and import everywhere. Here is what that looks like in code — on Keaz, every one of the twelve services is a thin application that inherits the platform by calling one factory:
// The platform is a library, not a team. Every Keaz service is a thin app that
// inherits the paved road by calling one factory — config, logging, health,
// database, and queue are solved once here and imported everywhere.
export function createService(name: string, register: (app: Hono, ctx: Ctx) => void) {
const env = Env.parse(process.env) // Zod-validated config: fail fast, never boot half-configured
const log = logger.child({ service: name }) // one structured log format across all twelve services
const db = makePool(env.DATABASE_URL) // shared, tenant-scoped Postgres pool
const queue = makeQueue(name, env.REDIS_URL) // BullMQ wiring: retries and dead-letter, default-on
const app = new Hono()
app.get('/healthz', () => db.ping()) // the golden path ships with its own health checks
app.get('/readyz', () => queue.ping())
register(app, { env, log, db, queue }) // the service adds only what makes it different
onShutdown(async () => { // drain in-flight work on deploy, then exit cleanly
await queue.close()
await db.end()
})
return serve(app, env.PORT, () => log.info('up'))
}
// A new service is a directory and ten lines — not a ticket, not a meeting.
createService('billing', (app, { db, queue }) => {
app.post('/charge', async (c) => {
/* only the domain logic that makes billing different lives here */
})
})The factory is about a hundred lines, and it turns the expensive, easy-to-get-wrong parts of running a service — config validation, connection pooling, health probes, queue semantics, graceful shutdown — into defaults nobody re-litigates. A new integration is a directory and a handful of lines, because everything that makes a service production-grade already arrived in the import. That is DORA's shift down made literal: the hard knowledge lives in one place, and the author of a new service never has to become an expert in it.
The minimum viable platform
If you are a small team, do not build a platform — install five capabilities, in this order:
- One golden path to ship. A single templated way to deploy a service — for Keaz that is a Docker Swarm stack file and one deploy command. DORA calls this the paved road; the point is that there is exactly one way, and it is boring.
- Self-service, not tickets. Standing up a new service is a directory plus a CI job the author runs. DORA's 2024 research tied this developer independence to a measurable productivity gain; at a small company it is the difference between shipping today and waiting on someone.
- Shift the hard parts down once. Auth, config, secrets, database pooling, and queue wiring belong in a shared bootstrap, not copy-pasted into every service. Solve the Kubernetes-shaped problems once — or, as I argued for Keaz, avoid them entirely by staying on Docker Swarm.
- Make failure cheap and recovery fast. Health checks plus a one-command rollback that returns you to the last good image in seconds. DORA's own framing is that a good platform makes failure cheap and recovery fast; it is the same capability I put at the center of shipping AI-generated code safely.
- Clear feedback on every deploy. One place to see deploy status, logs, and health. DORA found this is the platform capability most correlated with a good developer experience — if a deploy fails, the author should see why without asking anyone.
That is a minimum viable platform: a library, a stack file, a rollback command, and a dashboard — not an org chart. I built it on Keaz incrementally, one golden path at a time, exactly the way DORA recommends: find the most common workflow and make that one demonstrably better before touching anything else.
When you actually need a platform team
A platform team is a real and worthwhile hire — later. Three signals tell you the capability has outgrown the individual:
- More than one team is competing for the same golden path. When two or three squads want to change the deploy template in conflicting directions, someone has to own it as a product with a roadmap. That is a platform product manager's job, and DORA is explicit that a platform without a product owner drifts.
- Tenancy or compliance boundaries you cannot encode in a template. Regulated data residency, per-customer isolation guarantees, controls that must be enforced rather than documented — these need dedicated engineering, not a shared library.
- The platform must scale to teams you will never meet. Once contributors you do not personally onboard are extending the platform, you need clear APIs, a contribution model, and someone whose full-time job is keeping the paved road paved.
Until one of those is true, hiring a platform team is buying an org chart to solve a problem a library already solves. The failure mode DORA names — the ivory tower team dictating standards nobody adopts — is far more likely at small scale than the problem the team was hired to fix.
What this means for a founder
Here is the reframe that matters for the budget. If your AI coding investment has not paid off — if Cursor and Claude Code made your engineers faster but your releases did not speed up — DORA's data says the bottleneck is almost certainly downstream: testing, review, and deploy, not authorship. The fix is the paved road, and the paved road is a capability you can buy in weeks from one senior engineer, not a team you recruit over two quarters. That is the shape of work a fractional CTO does: install the golden path, the rollback, and the feedback loop so the speed you are already paying for actually reaches production.
My perspective
The opinion I will defend: at small scale, a platform team is a scaling decision disguised as a starting one, and treating it as a starting decision is how small teams end up both slow and over-hired. On Keaz I run twelve services on Docker Swarm with no platform team, because the twelve services share one bootstrap, one deploy path, and one rollback — the capabilities are real even though the team is one person. This is the same argument I have made twice from other angles: that the four delivery capabilities a small team needs before it scales AI coding are install-once, not hire-for, and that Docker Swarm, not Kubernetes, is the right substrate to install them on. The platform-team question is those arguments pointed at the org chart. Build the road first; hire the road crew when the road carries more traffic than one person can pave.
Recommended action this quarter
Time your new-service path. This week, take a stopwatch to one question — how long from idea to a running, health-checked service in production — and count how many other people the author has to wait on. If the answer is more than an afternoon, or more than zero tickets, you have a platform-capability gap, and it is throttling every fast tool you have bought. This month, extract one shared bootstrap so a new service inherits config, health, and queue wiring by importing it. By quarter's end, add the one-command rollback and a single deploy dashboard. None of that is a hire — it is the paved road, and it is what turns tools you have already bought into releases you can see.
Is your AI spend stuck upstream of production?
If your engineers got faster but your releases did not, the bottleneck is the paved road, not the tools. Book a time and we will map the gaps between your fastest tool and your slowest deploy — and install the capabilities that close them.