What an MVP is actually for

We build products for a living, and if there's one idea we'd press on every founder we work with, it's this one. An MVP, a minimum viable product, is not a cheap, slightly embarrassing version of the real thing. It's the fastest honest way to find out whether the real thing deserves to exist at all. Get it right and it saves you a fortune. Get it wrong and it's where the budget quietly disappears.

Minimum viable, not minimum effort

The word that earns its keep is viable. An MVP still has to deliver real value to a real person and hold up in their hands, because that's the only way it tells you anything true. What you cut is scope, the number of things it does. What you never cut is quality, how well it does them. A good MVP picks the single job that matters most, the riskiest assumption in the whole idea, and builds just enough to put it in front of real users and watch what happens.

Most of what you'd build, nobody uses

Here's the uncomfortable truth that makes the case for restraint. Most software is heavy with features nobody asked for. The Standish Group's long-running research into shipped software found that around 64% of features are rarely or never used, and only about a fifth are used often. Every one of those unused features was designed, built, tested, and then has to be maintained forever. An MVP is how you find the handful that genuinely earn their place before you spend a fortune on the rest.

The cheapest feature is the one you didn't build, because you found out in time that nobody wanted it.

Where teams get it wrong

We see two failure modes, pulling in opposite directions. One team ships something so thin it doesn't really work, learns nothing useful, and concludes the idea was bad when in truth it was the test that was bad. The other can't bear to launch anything imperfect, so the MVP swells into a year-long build that bets everything before a single customer has had a say. The craft is in holding the line between them: small in scope, serious in quality, and out of the door quickly.

From MVP to full build

A good MVP is never a throwaway prototype. We treat it as the ground floor of the building, made to be built on. The architecture, the data model and the way it's instrumented are all chosen so that version two means adding to what's there, not starting again. That's the difference between a demo and a foundation, and it's the part that's most tempting to skip and most expensive to get wrong.

Where AI fits

More and more, the riskiest assumption in a product is whether an AI feature is reliable enough to lean on. An MVP is exactly the right place to find out: prove it on one workflow, with a person checking the decisions that carry consequences, before it becomes load-bearing. Build the product, prove the intelligence inside it, then widen. It's the same discipline either way, simply pointed at the part most likely to surprise you.

We'd always rather put a small, real, working thing in front of your customers than a big, beautiful plan in front of you. You learn more from a week of genuine use than from a month of meetings. That, in the end, is what an MVP is for.