MVP development: what should be in version one?
· 6 min read
Minimum viable product has been used to mean so many things that it now mostly means "version one". Worth reclaiming the useful idea underneath it: the smallest thing you can put in front of real users that tells you whether the idea works.
Most MVPs are too big
The usual failure is not building something too small. It is spending nine months on a first version containing every feature anyone suggested, launching it, and discovering the core assumption was wrong. The cost of that mistake is the whole nine months.
A smaller first version does not just cost less. It fails cheaply, which is the entire point.
The test that settles most arguments
For each proposed feature, ask: if we launched without this, would we learn less about whether the idea works? Not "would it be worse" — almost everything makes it better. Would you learn less?
Password reset makes the product better. It teaches you nothing about whether anyone wants it. That does not mean shipping without password reset; it means password reset is not the thing to argue about in week one.
What usually belongs in version one
- The single core action the product exists to enable, done properly rather than partially.
- Whatever is needed to get a real user to that action — usually sign-up, and less than you think beyond it.
- Enough to take payment, if the question you are testing is whether people will pay.
- A way for you to see what users actually did, because you will otherwise be guessing.
What usually does not
| Commonly built too early | Why it can wait |
|---|---|
| Admin dashboards | You can run reports by hand at ten customers |
| Granular permissions | Add roles when someone actually needs a different one |
| Integrations with other tools | Valuable, but only once the core is proven |
| Mobile app alongside the web app | A responsive web app answers the question first |
| Onboarding tours and empty states | Worth doing once you know what confuses people |
| Anything for a customer segment you do not have yet | Speculation dressed as scope |
Manual is allowed
A surprising amount of version one can be a person doing something by hand behind the scenes. If approving a new account takes thirty seconds and you have four a day, that is not a feature — it is two minutes of somebody's morning, and building the automation costs a week you have not yet earned.
Automate it when the manual version becomes annoying. Annoyance is a reliable signal; anticipation is not.
Where cutting scope goes wrong
Minimum does not mean shoddy. The core action has to work properly, look credible and handle its own failures, because you are asking real people to judge the idea by it. Cutting features is right; cutting quality on the features that remain just tells you that people dislike a broken version of your idea.
Security and data handling are never part of the minimum you cut. A breach in version one ends the product regardless of how good the idea was.
Decide what would make you stop
Before building, agree what result would make you abandon or change direction. Teams that skip this tend to interpret any outcome as encouraging, and the MVP becomes a formality rather than a test.
If you are weighing a first version and want it costed and scoped before anyone starts writing code, that is what our MVP and SaaS work covers — including the harder conversation about what to leave out.
Working on something like this?
If any of the above describes your situation, describe it to us — no specification needed, and no obligation to proceed.
Keep reading
How much does custom software cost in 2026?Real ranges, what drives them, and why a quote given before discovery is a number someone made up.Custom software vs SaaS: which should your business choose?Most businesses should buy, not build. Here is how to tell whether you are the exception.