Solo Builds, 2-Person Teams, and Everything In Between

The most durable product I have built — a CRM still running five years after I shipped it — was a solo build. The one where I most needed a second person was the one where two of us still were not enough. Team size did not predict either outcome. The match between the team and the actual bottleneck did.

Most early-stage founders pick a team size to fit their ambition: big idea, so hire a few people. The right approach is the opposite. Match the team to the bottleneck in front of you, not the vision behind it. Early on, the bottleneck is almost never how many hands are typing — it is how fast you find out what to build. Adding people before you know that multiplies coordination, not output. So the honest default for a first build is one capable person, sometimes two, and a clear reason before you go past that.

When a solo build is the right call

A solo build wins when the bottleneck is decisions, not capacity — which is most of the time at the start. One person who can decide what to build, build it, and put it in front of a user has zero coordination cost. No standups, no handoffs, no translation loss between the person who understands the customer and the person writing the code.

RealEstateCRM was one person — me — shipping a plain apartments database in two weeks, then changing it almost daily based on how the agency actually used it. Automator was the same shape: solo, a working prototype in three weeks, then years of running on its own. Both are still live. They worked because they were solo. Every piece of feedback went straight from the user to the person who could act on it, with nothing in between.

The cost of a solo build is real and worth naming: there is no second opinion, no cover when you are sick, and you carry every hat at once — developer, product, support, the lot. I have done exactly that at early-stage startups, and it is draining. But for finding product-market fit, that tight loop beats a team almost every time. The constraint is your own bandwidth, and you trade speed of learning for resilience.

When a second person earns their place

You add a second person when the bottleneck genuinely splits in two — when there is more real, validated work than one person can hold, and the work divides cleanly enough that coordinating two people costs less than the output they add.

That second clause is where founders go wrong. Two people are not twice one person. There is a coordination tax: deciding who does what, keeping a shared picture of the product, not stepping on each other. If the work does not split cleanly, you pay the tax and get less than two people's worth of output. So the test is not "could I use more hands" — you always could — it is "is there a clean seam." Backend and a specialized domain. Build and a distinct go-to-market motion. Two products under one roof.

I have run two-person builds that worked well on exactly that basis. The second person is right when they own a seam you genuinely cannot, not when they are a faster version of you.

The case where two still was not enough

A larger team does not rescue a structural problem. I was part of a two-person build of an investment fund manager — LP onboarding, KYC and AML, deal tracking, reporting. The product shipped and it works; it is live today. We still handed it off to design partners.

The bottleneck was never hands. It was domain depth. Neither of us knew fund management well enough to keep making good calls as the scope grew, and we could not sustain that depth alongside other work. A third or fourth engineer would have produced more code in the same wrong direction. What the product needed was a different kind of person — someone who lived in fund operations — not a bigger version of the team it had. That is the trap of sizing to ambition: you scale the resource you have instead of the one you are missing.

How to actually decide

Before you add anyone, name the bottleneck out loud and check that a person is the fix:

• Is the constraint decisions or capacity? If you are still figuring out what to build, that is a decision bottleneck, and more people make it worse. Stay solo until the direction holds still.
• Does the work split on a clean seam? A second person is worth the coordination tax only when they own something distinct. No clean seam means you are buying overhead, not output.
• Is the gap a kind of person or a number of people? The fund manager did not need more engineers; it needed domain expertise. If you would add someone just like you, the team is probably already the right size.
• Can you feel the coordination cost yet? Two people who constantly sync are a sign the work was not separable. That is information — act on it before adding a third.

The honest answer for most first builds is one person who can decide and ship, with a second added only against a seam you can name. Everything past that should be pulled in by validated work, not pushed in by the size of the dream. I have built solo, in pairs, and across a wide range of scopes, and the products in the graveyard are rarely there because the team was too small. They are there because someone scaled the team before they had scaled the certainty.