What an MVP Is Really For (and Why Most Get It Wrong)

Every founder we meet wants to build an MVP. Almost none of them want what an MVP is actually for. They want a smaller, cheaper version of the product they've already decided to build. That is not an MVP. That is a down payment on a mistake you haven't caught yet.

The word has been worn smooth from overuse. It's worth putting the edge back on it, because the version most teams build quietly answers the wrong question.

The common definition is "the smallest version you can ship." Read it closely and you'll spot the assumption hiding inside: that the idea is already good, and all you need is a lean way to launch it. So teams strip the feature list to the core, ship it, watch a few people use it, and call that validation.

But a smaller version of a bad idea doesn't tell you the idea was bad. It tells you that you can build. Those are two different facts, and teams confuse them constantly.

The riskiest thing about most products isn't whether you can build them. It's whether anyone actually wants them. In CB Insights' long-running analysis of startup post-mortems, the single most common reason startups fail is building something the market didn't need. An MVP that only proves you can ship is answering a question nobody was losing sleep over.

Here's the reframe that changes how you scope one. An MVP exists to disprove your riskiest assumption as cheaply as possible.

Every product rests on a few load-bearing beliefs. Users will switch from the thing they use today. They'll pay what you think they'll pay. They'll do the slightly annoying thing your whole model depends on. Find the belief that, if it turns out false, kills the product. Then build the smallest thing that tests exactly that belief, and nothing else.

Sometimes that isn't even software. A landing page, a concierge service you run by hand, a manual back-end pretending to be automated. The point is a clean yes or no, fast, on the one thing that matters most.

If your MVP is designed so that every outcome feels like progress, you haven't built a test. You've built a way to feel busy while postponing the only question worth answering.

The costly part of a product was never the code. It's the decisions upstream of it: what you're building, who it's for, and which assumption you're betting the whole thing on. Those calls get made in week zero, before a repository exists, and they are the ones that sink projects six months later.

This matters more now, not less. [AI has made building fast and cheap](/services/ai-solutions). Speed has become the commodity. Judgment about what is worth building is the scarce thing, and it's getting scarcer as the building gets easier.

A team that can ship in a weekend but hasn't decided what question the build is meant to answer will simply reach the wrong destination faster. Cheap building doesn't remove the need for judgment. It moves the whole game onto judgment.

Strip away the theory and it comes down to five moves.

Name the riskiest assumption in one plain sentence. If you can't, that's the first thing to fix, because it means you don't yet know what you're testing.

Decide, in advance, what result would kill the idea, and mean it. An experiment you refuse to lose isn't an experiment.

Build only the thing that tests that assumption. Everything else is a distraction wearing the costume of progress.

Put it in front of people who would genuinely pay, not friends being polite. Read what they do, not what they say.

Leave room for the answer to be no.

When we start with a client, the first real conversation is almost never about features. It's about which belief the product is staking its life on, and how we'd know, quickly and cheaply, if that belief is wrong. When we built [DestinMe](/case-studies/destinme), the earliest questions weren't about the booking screen. They were about how a listing goes live, who controls pricing, what happens when a booking falls through. Get those right and the surface almost designs itself.

The best outcome of an MVP is sometimes that you don't build the rest. That feels like failure. It's the opposite. You spent a little to avoid spending a lot on something the market didn't want, and you got your runway back to point at a better idea.

If your MVP can only succeed, you haven't built an MVP. You've built the first expensive chapter of finding out the hard way.

If you're about to build one and you're not sure which assumption it's really testing, that's a good conversation to have before the first sprint. It's usually where we start too.