What Is an MVP and Why Every Startup Needs One

Most people think an MVP is the cheapest thing you can ship. That reading has cost founders more money than almost any other idea in startups, and it isn't what the term was supposed to mean.

Where the term actually comes from

Frank Robinson coined "minimum viable product" in 2001 at SyncDev. His definition was not "the smallest build." It was the product that maximises return on risk for both sides: maximum ROI divided by risk, for the company and for the customer. It came out of running product development and customer development at the same time, which he called synchronous development.

Steve Blank and Eric Ries popularised the term afterwards, and somewhere in that handoff "minimum" stopped meaning smartest bet and started meaning least effort. Those are different instructions. One asks what you most need to find out. The other asks what you can get away with.

The gap matters because the cheap reading gives you a broken product and no information. You learn that people won't use something bad, which you already knew.

What an MVP is for

An MVP is a way to buy evidence. Before you build, you are carrying a set of assumptions that will decide whether the business works:

• People have this problem badly enough to change what they currently do.
• They will use your particular solution to it.
• You can actually build it.
• The economics survive contact with real acquisition costs.

The MVP's job is to attack the assumption that would hurt most if it turned out to be wrong. Usually that is the first one, and usually it is the one founders skip, because it is the least fun to test and the easiest to answer with optimism.

If your MVP does not change what you believe, it wasn't an experiment. It was a launch with fewer features.

Building stopped being the hard part

Here is what changed, and it changed fast.

Shipping software used to be the bottleneck. It isn't. With current coding tools a competent team can put a working product in front of users in days. Y Combinator's Dalton Caldwell and Michael Seibel made the point directly in their 2026 talk on building an MVP in the AI coding era: when adding features is easy, it becomes easy to build something bloated that nobody asked for. A good MVP, they argue, is now as much about what you decide not to build.

That is the real shift. When building was expensive, scope discipline came for free, because you couldn't afford the extra features. Now nothing stops you. The constraint has to come from you.

And because building is no longer scarce, the build proves less than it used to. Having a product is not evidence of anything. What's scarce is demand, a way to reach people, and acquisition costs your model can actually absorb. None of those require your product to exist yet.

We'll say the obvious thing: we build MVPs for a living, so this is an odd argument for us to make. We make it anyway, because the alternative is watching founders spend their runway proving they can ship.

How to scope one

Write down the single belief that, if wrong, kills the business. Then design the smallest honest test of it.

Sometimes that is software. Often it isn't. A landing page that asks for money, twenty conversations with people who have the problem, a spreadsheet you run by hand for three customers. All of these produce better evidence than a half-built app, and they produce it in a week.

When it is software, cut to the one path that tests the belief. Not the whole product with everything at 40 percent. One thing that works properly, end to end. Users forgive missing features. They do not forgive the feature they came for being broken.

Then set the number in advance. What result would make you continue, and what result would make you stop? Deciding that after you see the data is how founders talk themselves into building for another six months.

The common failure

The MVP ships, a few people poke at it, nobody comes back, and the team concludes it needs more features. So they build for another quarter, and the same thing happens with more surface area.

Almost always the miss was earlier. The problem wasn't painful enough, or the people who had it were not the people being sold to. No amount of building fixes that, which is precisely why finding out early is worth so much.

The short version

An MVP is not a cheap product. It is the fastest honest answer to the question you are most afraid to ask about your own idea.

Build the smallest thing that tells you the truth. Decide beforehand what the answer means. Then believe it.