Quick checklist
- What's the one thing this has to prove?
- Who is the first real person who will use it?
- What would make you abandon the idea?
- Could a spreadsheet and a phone call test this first?
- What happens the day after it works?
MVP stands for minimum viable product. Both halves get abused.
The “minimum” half gets used to justify shipping something half-finished. The “viable” half gets quietly ignored. What’s left is a phrase that too often means “the cheap version”, which isn’t what it was ever supposed to mean.
The useful definition: an MVP is the smallest thing you can build that produces real evidence about the thing you’re least sure of.
Not the smallest version of your idea. The smallest thing that answers your riskiest question.
The question comes first
Every software idea rests on assumptions. Some are safe. One or two, if you’re honest, are the ones the whole thing depends on:
- Will people actually use this rather than what they use now?
- Will they pay for it?
- Can this technically be done at a sensible cost?
- Will this genuinely save the time we think it saves?
Your MVP should be built to answer whichever of those you’re least certain about. That’s what decides the scope — not a feature list, and not what looks impressive.
If you’re unsure whether people want it, build something small and put it in front of real people quickly. If you’re unsure whether it’s technically feasible, build the hard part first and nothing else. Those two produce completely different first versions, which is why “build an MVP” isn’t specific enough to act on.
What goes in the first version
A useful test for each feature: if we removed this, would the experiment still answer the question?
If yes, it goes in version two. Almost everything goes in version two.
Things that people routinely put in a first version and shouldn’t: user roles and permissions, settings screens, an admin area for things you can change in the database yourself, reporting, exports, and anything that exists because “we’ll need it eventually”.
Things people routinely leave out and shouldn’t: a way to know whether it’s being used, and a way for the first users to tell you what’s wrong. An MVP that generates no information has failed at the only thing it exists for.
The three ways it goes wrong
Building version one of everything instead of all of one thing. Ten features at 10% each is not an MVP — it’s an unusable product. One feature that works properly is a test. Ten that half-work test nothing except your patience.
Confusing minimum with rough. The parts you do build have to work. If people won’t use it because it’s frustrating, you learn nothing about whether they wanted it. The scope should be small; the quality shouldn’t be.
Never leaving MVP. The most expensive one. The first version works, gets used, and becomes permanent — with all the shortcuts that were fine for an experiment now baked into something the business depends on. It’s worth deciding up front which shortcuts you’re prepared to live with and which get fixed if it succeeds.
When you don’t need one
When it isn’t risky. If you’re building an internal tool to replace a spreadsheet you already use daily, you know it’ll be used and you know what it needs to do. There’s no assumption to test — just build the thing properly.
When something simpler tests it. A landing page, a form and a phone call has killed a lot of bad ideas cheaply. So has running the process manually for a month to see whether anyone cares. If a person doing it by hand can prove the demand, do that first — it’s faster and vastly cheaper than software.
When “minimum” would embarrass you in front of the only customers you’ll get. If your market is six businesses and you know all of them, you may only get one attempt. That changes the calculation.
What we’d ask you
If you brought us an idea, this is roughly the conversation, and it’s usually shorter than people expect:
- What’s the one thing this has to prove?
- Who is the first real person who’ll use it, and when could they?
- What would you have to see to decide to stop?
That third question is the one that gets skipped, and it’s the most valuable. An MVP with no defined failure condition isn’t an experiment — it’s the first instalment of a project you’ve already committed to.
The unglamorous truth
Most good first versions are smaller and less interesting than the person who had the idea wants them to be. That’s not us being unambitious; it’s that the point of the exercise is to find out something you don’t currently know, as cheaply as possible.
Being wrong after six weeks and a small budget is a good outcome. Being wrong after a year is the thing an MVP exists to prevent.
If you’ve got an idea and you’re not sure how small the first version should be, that’s exactly the conversation to have before anyone writes code — and it’s what the free systems review is for.
Bottom line
An MVP is the smallest thing that produces real evidence about the riskiest assumption. If a feature isn't testing that assumption, it belongs in version two.
Want a hand with this?
Tell us what you're trying to sort out and we'll give you practical, plain-English advice before you spend money.
