Why most MVPs fail by month three.

Last month a founder we'd been emailing with finally got on a call. He'd just spent eight weeks shipping his v1. Beautiful onboarding. A pricing page that actually converted. Stripe wired up properly. He launched on a Tuesday, got 200 signups in 48 hours, and by the following Tuesday his dashboard was flat.

Three months later he was still building. New features every week. None of them moved the needle. By the time we talked, he had four months of runway and a codebase he didn't want to look at.

His code was excellent. His product still failed.

We see this a lot. It's the most common shape of MVP failure we run into, and it's almost never about the engineering. So this note is about the three reasons it keeps happening, and what we tell founders to do instead.

The three reasons

1. They built the wrong thing because they didn't talk to enough people. The hypothesis lived inside the founder's head for too long. By the time real users saw v1, the idea was load-bearing for the founder's identity. Negative signal at that point feels like an attack, so it gets explained away. “They didn't get it.” “Wrong segment.” Six weeks later, more features. Same problem.

2. They built too much. MVP used to mean “the smallest thing that proves the hypothesis.” Somewhere along the way it got redefined as “the smallest thing we're not embarrassed by.” Those are very different products. The first ships in two weeks. The second takes two months and arrives carrying a lot of emotional weight.

3. They have no usage signal. No event tracking. No activation funnel. No retention chart. So at month three, when the question becomes “is this actually working?”, the only available answer is a vibe. Vibes don't raise a Series A. Vibes don't pay salaries. Vibes definitely don't survive a board meeting.

What to do instead

Most of this is unglamorous. None of it requires a special framework.

1. Talk to thirty people. On calls. Before any code. Not surveys. Not Twitter polls. Real conversations where you can hear someone hesitate. The first ten will be confusing. The second ten will start to rhyme. By the third ten, you know whether this is real. If you can't find thirty people willing to talk to you about the problem, that's your answer.
2. Define done as “a real person used it for a real reason and told us about it.” Not “feature shipped.” Not “design approved.” Used. Reacted to. That single change in what counts as done changes what you build, in ways that are obvious in hindsight.
3. Measure activation, not signups. Signups are vanity. Activation is the moment a user does the thing the product is for. It's the only number that tells you the hypothesis is alive. Instrument it on day one. Look at it every Monday.
4. Ship in weeks, not months. The first version should embarrass you a little. If it doesn't, you waited too long. The longer you wait, the more loaded the launch becomes, and the harder it gets to hear the signal honestly. Ship ugly. Ship Tuesday. Ship before you're ready.
5. If five out of thirty conversations don't say “yes I'd pay for this” before you start, don't start. Or rather: start something else. Pivoting after launch is expensive. Pivoting before launch is free.

When a studio makes sense (and when it doesn't)

A studio (us, or someone else) makes sense if you have signal but not the technical bandwidth, if you need to ship fast and don't have a senior engineer in-house, or if you want a partner who'll tell you to stop rather than charge you for more.

A studio doesn't make sense if you haven't talked to your users yet, if you're looking for the cheapest hands you can find, or if you want a yes-team. None of those are bad things to want. They're just not what we are.

The shape of MVPs that survive

The MVPs that work look surprisingly similar. Small surface area. A clear use case. Real users. Weekly improvement. A founder who can quote three customers from memory. The ones that fail look surprisingly similar too. Big surface, vague use case, no users, no signal, no survivors.

If you're about to start an MVP and want a sanity check before you commit eight weeks of build, we'll give you one. Free, 30 minutes, no commitment. Worst case, we confirm what you already think. Best case, we save you a quarter.