How a tiny team runs a five-business fleet

The model most teams still run

Most software delivery is organized around large teams, heavy ceremony, and manual coordination. Standups, sprint planning, retros, ticket grooming, status meetings. A lot of that work is real, but a lot of it is coordination overhead that exists because the team is large, not because the product needs it.

That model has a ceiling. Throughput caps out. Experimenting across multiple products gets expensive because every product needs its own slice of the team and its own coordination tax. We started from that same baseline. It did not scale to a fleet.

What we changed

We treat AI as a first-class engineer, not a sidekick that occasionally writes a function. Concretely, four things.

Briefs, not vibes

Every meaningful piece of work starts with a written brief. The brief states what we are building, the constraints, how we will know it worked, and explicitly what we are NOT doing. A brief is testable: if a fresh AI session cannot execute it end to end, the brief was the bug, not the code. The constraints section is always the most important part.

One operating layer across all products

We built an internal system that holds the fleet's policies, frameworks, audit rubric, and the patterns we have learned. Every product inherits from it. A standard a new repo needs is not re-derived; it is referenced. When we improve how we work, the improvement propagates to every product instead of staying trapped in one.

Compounding pattern capture

When we hit a problem, we fix it and we write it down. In one recent two-day build we hit and logged sixteen distinct trip-wires: a broken SDK, an auth edge case, a build-config gotcha. Most teams Slack-thread those fixes and forget them, then rediscover them on the next project. We do not. The ledger means the second time anyone on the team hits the same shape, the answer is already written.

We audit ourselves

Every fleet product gets scored against a six-dimension rubric: structure, AI-readiness, testing, security, compounding, code quality. When all three products hit the top of the rubric, we did not declare victory. We found the rubric had stopped being useful, rewrote it to a harder version, and ran a real vulnerability scan that the old rubric never asked for. The audit improving itself is the system working.

What it actually looks like

Real examples from the last stretch of work, with real numbers, because vague claims are worth nothing.

The cultural part

This is not only a tooling change. The harder shifts were about how we work.

• Less ceremony. Fewer mandatory meetings. More asynchronous, written updates. The written brief replaces the planning meeting; the audit report replaces the status meeting.
• End-to-end ownership. A small team owns a product's outcomes, not a handoff stage. Nothing gets thrown over a wall.
• AI is expected, not heroic. The job is to design work so AI can do most of it well, not to hand-craft everything yourself.

The honest part

Here is what this field note will not do, because the internet has enough breathless AI-engineering content already.

I am not going to tell you we are 25x faster than a 10-person team. We have never had a 10-person team on these codebases. There is no baseline to multiply against. Anyone who quotes you a number like that for their own shop should be asked, politely, where the baseline came from.

What I can tell you honestly:

• This works at our scale. Our products serve hundreds of users, not millions. A discipline that works at hundreds is not automatically proven at millions, and I will not pretend otherwise.
• We do not yet have production observability wired up. When something breaks, we currently find out from a customer message, not a monitoring alert. That is the next thing on our list.
• Our automated test coverage is thinner than it should be. Strict typing catches a lot. It does not catch everything.
• We have not been through a real incident yet. Our incident-response process is written down but untested by reality.