The founder’s dilemma: launch now, or build a little more?

There is a moment in almost every product’s life when it is nearly ready. The core flow works. A few people have seen it and liked it. And yet there is always one more thing: a missing setting, an onboarding step that feels rough, a feature a potential customer mentioned on a call.

This is the founder’s dilemma. Launch now and risk showing people something unfinished, or keep building and risk spending months on things nobody asked for. Both paths have real costs, and the advice you hear online tends to pick a side. “Ship early and often” sits on one end, “you only get one first impression” on the other. Neither is wrong. Neither is universally right either.

Both choices cost something

It helps to be honest about what you are trading, because the costs of waiting are easy to miss while the costs of launching feel very visible.

Launching early can cost you:

• A weak first impression with people who may not come back.
• Feedback that is really about missing basics rather than your core idea.
• Support load and bug fixing that pulls the team away from planned work.
• Trust, in areas like health, finance or anything involving personal data, where mistakes carry real consequences.

Waiting can cost you:

• Runway, spent on features that may not matter.
• Learning, because you are still guessing about what users actually need.
• Momentum, both for the team and for anyone who was waiting to try the product.
• Timing, if the problem you are solving is getting attention from others.

The question is rarely whether the product is perfect. It is whether it is ready to teach you something.

What “ready” actually means

Most arguments about launching are really arguments about the word “ready”. A useful definition is: the smallest version of the product that tests your riskiest assumption, without harming the people who use it.

That turns a feeling into a few questions you can answer:

• Does it solve one clear problem from start to finish?
  
• Can a new user get value without you walking them through it on a call?
  
• If something breaks, is the damage limited to inconvenience rather than lost money, data or safety?
  
• Will you be able to tell whether it worked?
  

If you can answer yes to all four, you probably have enough to learn from. If one of them is a firm no, that is usually the thing to fix before launch, not the list of nice-to-have features.

Michael Seibel’s Startup School talk on planning an MVP is a practical look at how small that first version can be, and at how much you can learn from it.

When waiting is the better call

There are good reasons to hold back, and they tend to be about risk rather than polish:

• Regulated or high-stakes products. Health, finance, legal and anything handling sensitive data need a higher bar before real users arrive.
• Hardware and physical products, where changes after launch are slow and expensive.
• Enterprise sales, where buyers run long evaluations and a poor first trial can close the door for a year.
• A broken core experience. Missing features are fine. A main flow that does not work is not.

When launching is the better call

On the other side, shipping sooner usually makes sense when:

• Changes are cheap to make, which is true for most web and mobile software.
• You are still guessing about demand, pricing or which audience cares most.
• You have a small group of people you can talk to directly and learn from.
• The features you are adding are based on your own assumptions rather than on what users have asked for.

Ways to lower the risk either way

The choice is not only “public launch” or “keep building”. There are plenty of steps in between:

• A private beta with a waitlist or invite codes, so you control who arrives and when.
• A narrow launch to one segment, one city or one type of customer.
• An honest label. Calling something a beta, and meaning it, sets expectations and invites feedback.
• Separating launch from announcement. You can put the product live quietly and make noise later, once it holds up.

Y Combinator’s Kat Mañalac makes a related point in her talk on launching: a launch does not have to be a single big moment. Many products launch several times, to different audiences, as they get better.

Decide how you will judge it before you look at the results

Whatever you choose, write down in advance what would count as success and what would make you change course. For example:

1. The one behaviour that shows the product is useful, such as a repeat visit or a completed task.
2. The number you would be happy with, and the number that would worry you.
3. The date you will review it.
4. What you will do in each case.

It sounds simple, but it protects you from a very human habit: reading the results in whatever way supports the decision you already wanted to make.

There is no universal answer to the founder’s dilemma. Some products should launch far earlier than their founders are comfortable with, and some genuinely need more time. The one choice that tends to go badly is not choosing at all, and letting the launch date drift because “ready” was never defined.