Product

What an MVP is, and when you need one

The term is used for everything from a sketch to a half-finished product. What it actually means, and when it is the wrong approach.

Published 8 August 2026

MVP is one of the most worn-out words in software. It gets used for a sketch, for a demo, and often simply for a product that is not finished. That is a shame, because the original idea is useful: the smallest version that answers a real question.

Minimum refers to the question, not the quality

The misunderstanding sits in the word minimum. It is about how many features you build, not how well you build them. An MVP that falls over, runs slowly, or loses data answers nothing: users leave because of the quality and you learn nothing about the idea. Small in scope, normal in soundness.

The question first, then the build

Before anything gets built, there should be a sentence on paper starting with: we think that. For example, we think installers will assemble their own quotes if they can see tiered pricing directly. That sentence decides what version one needs and, more importantly, what it can do without. Without it you build everything anyone thought of and still know nothing afterwards.

When an MVP is the wrong approach

When you already know the answer. Replacing a process that demonstrably works but is manual leaves nothing to validate. Just build it properly.
When it cannot be half-done. For financial processing, medical data, or safety, a stripped-back version is not an experiment but a risk.
When you only get one launch. One shot at a major client or one trade fair means a half impression is worse than waiting.
When the organisation will not treat it as an experiment. Once the first version is live everyone starts using it and the budget for version two evaporates. That is expectation management, not engineering.

Build the foundation properly from the start

There is a difference between few features and badly built. The data models, the architecture, and how data is stored must be right from day one, even when the first version is small. That costs barely any extra time and saves months if it lands. What you do leave out: everything only needed at a scale you do not have yet.

Agree what success means before you launch

The question after launch is always: do we continue? Without a prior agreement that becomes a matter of feeling, and the loudest voice wins. Write down what you are steering on and what the floor is. How many people use it, how often, and for what. Even when the answer is no, you have learned something for a fraction of the cost.

Frequently asked

How does it differ from a prototype?

A prototype shows how something would work, usually with nothing real underneath: clickable screens to test an idea. An MVP genuinely works and is used by real users for real work. A prototype tests whether people understand it; an MVP tests whether they use it.

How long does an MVP take?

With a sharply bounded question, weeks rather than months. When it overruns, it is almost always because scope grew during the build. That is the signal to go back to the sentence beginning with: we think that.

Can we build on it if it lands?

Yes, provided the foundation is right from the start. Which is exactly why we put that down properly straight away. A first version you have to throw away costs more than it looks, because you pay for it twice.

Should we show it to customers or keep it internal?

Show it to real users, or you are measuring nothing. Do it with a limited group who know it is a first version. Colleagues make poor testers: they are too kind and already know the intent.