Notes on Building Small

There's a persistent assumption that ambition requires size: more people, more capital, more features, more everything. I've come to believe the opposite is usually true. The most interesting work I've seen came from small teams who couldn't afford to do it any other way.

These are some notes on why.

Small is fast

Communication cost grows faster than headcount. Two people have one conversation to maintain. Ten people have forty-five. Every person you add makes every decision a little slower, a little more negotiated, a little more averaged.

Small teams skip most of that. They decide over lunch and ship by evening. Speed isn't just a nice property — it compounds. A team that can run ten experiments in the time it takes another to run one doesn't just move faster; it learns faster, and learning is the only durable advantage.

Small is honest

When a project is small, there's nowhere for bad ideas to hide. You can't bury a weak feature in a roadmap with forty others. You can't mistake activity for progress when there are only three people and everyone can see what everyone else is doing.

Constraints don't limit good work. They reveal it.

Large budgets make it possible to keep funding things that aren't working, because nobody has to choose. Small budgets force the choice early, which is exactly when it's cheapest to make.

Small bets, often

The best way I know to handle uncertainty is to make many small bets rather than a few large ones:

1. Each bet is cheap enough that losing it doesn't hurt much.
2. Each bet teaches you something, win or lose.
3. The winners can be scaled; the losers can be forgotten.

This is how good investors size positions, how good scientists run experiments, and how good builders find products. Nobody knows in advance which idea will work. The trick is to arrange things so you don't have to.

What small doesn't mean

Building small isn't the same as thinking small. Some of the most consequential tools in the world were built by a handful of people. Small describes the approach, not the ambition.

It also isn't permanent. When something clearly works, it should grow. The mistake is growing before you know what works — scaling up a guess and calling it a strategy.

A short checklist

Before adding anything — a person, a feature, a process, a dependency — I try to ask:

• Does this make us faster or slower next month?
• Could we get eighty percent of the value with twenty percent of the size?
• If this turns out to be a mistake, how hard is it to undo?

Most of the time, the honest answer points toward staying small a little longer. And most of the time, that turns out to be right.