MVP: Why Your Software's First Version Should Be Smaller Than You Think

The first feature list is always long. Bookings, payments, notifications, statistics, a loyalty scheme, apps for iPhone and Android, maybe a smart assistant. Every item feels essential.

The reason is simple: at that point every feature is imagined, none has been used yet. And the most expensive mistake in software development isn't building badly. It's building something well that nobody then uses.

MVP stands for Minimum Viable Product: the smallest version of the product that genuinely solves the main problem, for real users. It's not a prototype to show off, not a demo, and above all not a rushed version. It's a complete product with a narrow scope.

There's a well-known illustration by Henrik Kniberg that explains it better than any definition. If the goal is to get around, you don't build a wheel first, then a chassis, then a body, leaving the user on foot until the very end. You start with a skateboard, then a scooter, then a bicycle. At every step the user has something that takes them somewhere, and at every step you learn what they really need.

You find out early what's really needed. People use software in ways no meeting can predict. The sooner you put it in their hands, the sooner you find out.

Mistakes cost less. If a feature turns out to be useless, better to learn it on a small project than after months of development.

You reach real use sooner. Weeks instead of quarters. And software in use starts delivering value straight away.

Later decisions rest on facts. From the second version on, you're no longer debating assumptions but how people actually use the tool.

Take the feature list and split it into three groups: essential from day one, useful but can wait, nice to have. Then ask one question of every item in the first group: if this feature were missing, would anyone stop using the product? If the answer is no, it moves down a group.

A second question helps cut further: what can be done by hand at first? Approving a request, sending a report, handling an exception. Doing it manually for a few weeks costs little and tells you whether it's worth automating.

Here's how the split might look for a booking platform.

I wrote a dedicated comparison on that last row in PWA or Native App? What a Progressive Web App Is and When It's Worth It.

This is the difference between an MVP and a job done on the cheap. The scope is narrow, but the foundations are those of a product meant to grow: security, a well-designed data structure, code that can be extended without being rewritten.

You cut features, not foundations. A badly built MVP isn't a first version: it's a prototype you'll have to throw away.

There are cases where starting small doesn't work, and it's only right to say so.

If you're replacing a tool the business uses every day, people won't accept going backwards: the core functions of the old system need to be there from day one. You can narrow the scope on everything else, but not on that.

If you work in a sector with specific obligations — health data, payments, industry regulations — some requirements aren't features to postpone but conditions for starting at all.

It's the same reasoning as the third way I described in Custom management software or a subscription: build only the piece you need, and build it well.