Why we build small products instead of one big one

A large product is a compounding liability before it is a compounding asset. Every additional surface has to be designed, built, supported, documented, and kept alive through platform changes. Before a single person has used it, it already costs something to exist.

The deeper issue is feedback. A big build defers the only question that matters — does anyone want this — until after most of the money and time is gone. By the time the answer arrives, the honest response to it is unaffordable.

Small is not cheap or unambitious. Small means the product does one job for one kind of person, and the boundary is drawn on purpose.

Trade Estimate AI produces an estimate. Ghosted notices you left your desk. Onus holds you to a commitment. None of them try to be the last app you will ever open, and that constraint is what makes each one finishable and legible.

Any single product can fail for reasons that have nothing to do with quality — a category that is already saturated, a platform policy change, timing. Held alone, that failure is the whole business. Held in a portfolio, it is one data point about a market.

The portfolio also compounds internally. Auth, billing, error reporting, transactional email, and release process are built once and reused. The fifth product is meaningfully cheaper than the first, and it is cheaper because of work that was already paid for.

The hard part is not building small. It is refusing to let a small thing quietly become a large thing. Every product accumulates requests that are individually reasonable and collectively fatal to the original boundary.

The rule we apply: a feature has to serve the one job better, or it goes into the notes file as a candidate for a different product. Most of them belong there. Some of them turn out to be the next thing worth building.

The same logic holds when we build for someone else. The first engagement should produce something real and finished, not a phase one that only makes sense if phase two is funded.

If the honest answer is that a project needs to be large, that is worth knowing before it starts. Most of the time, a smaller version answers the same question faster and costs a fraction of the guess.