How a Small Team Ships Like a Larger One

People assume a small studio is a tradeoff: fewer hands, less throughput, narrower scope. In practice the opposite tends to be true on the work that matters. The constraint is the advantage — it forces a kind of discipline that larger orgs have to manufacture.

Here is how we actually work.

Senior by default

Every person who touches the code has shipped real systems and carried real pagers. That isn't a vanity stat; it changes the shape of the work. There's no tier of the team that needs everything spelled out, no translation layer between "the people who decide" and "the people who type." The person designing the system is the person building it and the person who'll own it.

That collapses a lot of overhead. Fewer handoffs, fewer specs written to be misread later, fewer decisions made by someone who'll never feel their consequences.

Architect before you accelerate

We spend real time at the start drawing the boundaries — what the pieces are, where the seams go, what the data is allowed to do. It feels slow on day one and pays back every day after.

// A boundary you can see in the types is a boundary you can trust.
type Cents = number & { readonly __brand: "Cents" }

function toCents(dollars: number): Cents {
  return Math.round(dollars * 100) as Cents
}

A money value that can't be confused with a plain number, a module that can't reach into another's internals, a state machine that can't enter an illegal state — these are decisions made once, at the edge, that quietly prevent whole categories of bug for the life of the project.

Optimize for the second engineer

The first version is easy; anyone can make something work once while it's fresh in their head. The real test is the second engineer — the one who shows up later, with none of that context, needing to change one thing without breaking three others.

So we write for that person. Names that survive being read out of context. Tests that explain intent, not just exercise lines. Comments where the why isn't obvious from the what. The reward isn't aesthetic — it's velocity that holds up instead of decaying.

Ship, then sharpen

None of this is an argument for polishing in a cave. Working software in front of real usage tells you more than any amount of planning. We get something real running early, then sharpen it against contact with reality — tightening the parts that turned out to matter and leaving the parts that didn't.

Small team, real weight. It's not a tradeoff. It's a way of working.