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:

• We size the architecture to what each project actually needs, and we decide that at the start rather than discovering it later. Where we have not run at a given scale, I will say so plainly rather than imply otherwise. That is the question I would put to anyone quoting you a number.
• Observability was a genuine gap when I first drafted this note, and closing it taught us more than shipping features did. Our newest product now runs automated self-checks on a schedule that stay silent unless a threshold trips, so quiet means healthy rather than unknown. That pattern is the model we are rolling out across the older products, and writing down how you would find out something broke turns out to be most of the work.
• The method is a little over a year old. It has survived a full cycle of AI tooling churn, which is the only stress test that counts in this field right now. A year is still a year, though. I would not call it settled.
• The real constraint is bandwidth, not method. A small team running five businesses has to say no far more often than yes, and choosing what not to build is the part we are still getting better at.