When You Should Not Build an MVP Yet

We build software for a living, so this is against interest to say: quite often, the right first move is not to build an MVP. Founders reach for "let's build an MVP" as a reflex, the way you'd reach for a hammer. But an MVP is one test among several, usually the most expensive one, and reaching for it first can burn time and money answering a question a cheaper test would have settled in a week.

Knowing when not to build yet is as valuable as knowing how to build well.

The point of an MVP is to answer a question: will people want this, use this, pay for this. Building software is one way to get that answer. It's also the slowest and priciest way, because you have to build before you learn.

So before you commit to it, ask whether the specific thing you need to learn actually requires a working product. Often it doesn't, and reaching for a build is answering a cheap question with an expensive tool.

Some things a built MVP genuinely tests: whether people can use the thing, whether the experience holds together. But plenty of the riskiest questions don't need code at all.

Will people pay? A landing page and a real checkout intent can tell you. Do they even have the problem? Ten honest conversations will tell you more than a launch. Will they switch from what they use now? That's about behaviour and incentives, and you can probe it before writing a line. When the risky assumption is about desire, willingness, or behaviour, a build is a slow way to learn something a conversation or a fake door reveals in days.

There are clear signs you're not ready to build. You can't name, in one sentence, the single assumption the MVP would test. You haven't spoken to enough real potential users to know the problem is real. You're reaching for a build because it feels like progress, not because it's the cheapest way to learn the next thing.

In all three cases, building is procrastination that looks like work. The cheaper move is to go get the answer that's blocking you, by talking to people, by testing willingness, by faking the door, before you spend a sprint building on a guess.

None of this means never build. It means build when you've exhausted the faster ways to learn, when the remaining risk genuinely lives in whether the product works rather than whether anyone wants it. At that point an MVP is exactly right.

The discipline is sequencing. Use the cheapest test that can answer the question in front of you, and only escalate to building when nothing cheaper will do. The founders who waste the least money aren't the ones who build fastest. They're the ones who build last, after everything cheaper has already told them the idea is worth it.