Why Small Engineering Teams Should Ship One Product at a Time

The default advice for an early-stage team is usually some version of "run parallel bets so you are not dependent on one idea working." That advice makes sense for a team with the headcount to genuinely staff more than one product. For a small team, it is usually a way of turning one focused problem into three unfocused ones. We build one product at a time, on purpose, and have kept doing it through three products because it is the only way we have found to actually finish things instead of accumulating half-finished ones.

This is not a philosophical stance about focus for its own sake. It is a practical response to a specific cost: context switching. When the same small set of engineers is splitting attention across two or three codebases in a given week, every switch back to a product means re-loading the state of that codebase into your head — which decisions were made and why, what is half-refactored, what the current known bugs are. That reload is not free, and on a small team there is no one else to hand the context to while you are away. The cost shows up as slower velocity on every product at once, which is the opposite of what parallel bets were supposed to buy you.

What "ship before starting the next" actually means

Sequential does not mean waiting for a product to be perfect, or for growth to plateau, before starting anything new. It means getting a product to a state where it is live, being used by real people, and not actively falling over — and only then reallocating the team's primary attention to the next thing. Existing products do not get abandoned; they move from "the whole team's focus" to "maintained, with a clear owner," which is a very different mode of work than active building.

How this actually played out for us

We built WorkHub first. It forced us to get serious about security architecture — access control, data isolation between organizations, the kind of infrastructure decisions that are expensive to bolt on later and cheap to get right at the start when you only have one codebase to think about. Building TalkBetter next, we carried that security discipline forward, and the new problem it forced on us was reliable AI evaluation under messy real-world conditions — unstable networks, honest scoring pipelines, and where humans still own consequential judgments. That pattern, AI drafts and a person decides, is now something we apply everywhere, including to how we use coding agents on our own codebase.

TalkBetter came next and forced us into a different kind of problem entirely: evaluating spoken language reliably, and making a media-heavy product hold up on the kind of shared, unreliable campus networks a typical office network never resembles. That is where the chunked upload pattern we have written about elsewhere came from — a problem we would not have taken seriously if we had been splitting attention across three products and treated it as an edge case to fix later. Dima, our current product, is a financial data tool, and it inherited a demand for data integrity that is non-negotiable in a way the earlier products' problems were not — you cannot ship "mostly correct" numbers and call it acceptable. Building it with the discipline the previous three products had already forced on us made that a much shorter conversation than it would have been starting from zero.

Each product genuinely taught us something the next one needed. That compounding only happens if you finish one thing with your full attention before splitting it. If we had built all four in parallel from day one, we believe — though we cannot prove a counterfactual — that we would have four weaker products instead of four that each stood on what came before.

None of these transitions were clean in the way a case study makes them sound in retrospect. There were stretches building TalkBetter where a WorkHub client issue pulled someone's attention for a few days, and stretches on Dima where a TalkBetter bug report needed the one person who understood that part of the system best. Sequential does not mean a hard wall between products; it means the default allocation of attention is one product at a time, with the earlier ones handled as focused exceptions rather than as an equal, ongoing claim on the team's time.

How we actually decide when to move on

The hardest part of this approach is not the discipline of staying focused — it is deciding when a product has reached the point where the team's primary attention can move. We do not use a fixed timeline or a specific user count as the trigger, because those numbers do not tell you whether the thing is actually stable. The real question we ask is narrower: is the product live, is it being used by people who are not us, and can it run for a stretch without the whole team needing to drop what they are doing to keep it upright. Once the answer is yes, it moves to maintenance mode with a clear owner, and the next product gets the team's attention. That owner is still one of us, not a separate support function we don't have — on a small team, maintenance is a responsibility you carry alongside whatever you build next, not something you hand off and forget.

The team-size math nobody puts on the roadmap slide

Parallel roadmaps are usually pitched with a team-size assumption baked in that goes unstated: you need enough engineers that each product has a real owner, not a shared pool of the same few people getting pulled between three Slack channels in the same afternoon. A team large enough to genuinely run two products in parallel does not experience the same context-switching cost we are describing, because the people working on product A are simply not the people working on product B. We are not that team, and being honest about that is most of the argument. A five or six person engineering group splitting itself across three products is not running three smaller parallel bets — it is running one team's worth of attention divided by three, with the coordination overhead added on top instead of subtracted.

The temptation to jump early, and why we resist it

The hardest moment in this approach is not the discipline of finishing — it is the week when the current product is stable but not exciting anymore, and a new idea feels obviously more interesting to work on. That is precisely the moment sequential shipping is protecting against. A product that is live and working but still needs steady iteration — bug reports, small feature requests, the unglamorous maintenance that keeps users happy — is easy to under-invest in once something shinier is available to think about instead. We have caught ourselves wanting to start the next thing early more than once, and the discipline is specifically noticing that impulse and checking it against the actual criteria — live, used by real people, stable without constant firefighting — rather than against how bored the team currently feels with the current problem.

The honest tradeoff

Sequential shipping is a bet that depth beats breadth for a small team, and it is a real tradeoff, not a free lunch. We are not testing four ideas in the market at once; we are testing one at a time, which means if an idea is a genuine dead end, we find out about it later than a portfolio approach would tell us. There is also an opportunity cost we cannot fully measure: some idea we have not built yet might have been the better bet, and sequencing means it waits its turn regardless. We have made that trade deliberately, because the alternative we can observe directly — three mediocre products advancing slowly instead of one good product advancing quickly — has not looked better to us in practice, even if we cannot prove the counterfactual where we tried it the other way.

This is also how we approach client work under Product Engineering: one engagement gets the team's full attention rather than being one of several concurrent projects competing for the same few engineers. If that kind of focus is what you are looking for in a build partner — a team that finishes what it starts before picking up something new — that is the conversation worth having with us.