An MVP is an experiment
The purpose of a minimum viable product is to learn whether your core assumption is true — that a specific user will adopt, and ideally pay for, a specific solution. Every feature should be judged by whether it helps answer that question.
Write down your riskiest assumption
Is the biggest risk that users don't have the problem, won't change their behaviour, or won't pay? Each risk suggests a different MVP. Being explicit avoids building a polished product that tests nothing.
What usually belongs in an MVP
- Simple sign-up and login.
- The single core workflow that delivers the main outcome.
- Just enough onboarding to reach that outcome.
- Payment, if willingness to pay is part of the test.
- Analytics and a way to collect feedback.
What can usually wait
- Complex permission systems and enterprise features.
- Extensive settings and customisation.
- Native mobile apps, if a responsive web app will do.
- Integrations that only a few users need.
Prototype before you build
A clickable prototype tested with five to ten target users can reveal major usability and value problems in days. It's the cheapest stage at which to change your mind.
Measure what matters after launch
Track activation (did users reach the core outcome?), retention (did they come back?) and qualitative feedback. These signals decide whether to iterate, expand or rethink.
Example: scoping an MVP
Imagine a tool that helps small clinics reduce no-shows. The riskiest assumption is that clinics will connect their calendar and let the tool send reminders. The MVP therefore needs sign-up, a calendar connection, reminder templates and a simple report of confirmed appointments. Multi-location support, custom branding and advanced analytics can wait until clinics are actively using the core flow.
Budgeting for an MVP
MVP budgets vary widely with scope, integrations and design requirements. The most effective way to control cost is ruthless prioritisation: every feature should map to a hypothesis. Reserve part of the budget for the iteration that follows launch — the first version is never the last.
After launch: what to watch
- Activation rate — the share of sign-ups who reach the core outcome.
- Time to value — how long it takes a new user to get there.
- Week-one and month-one retention.
- Qualitative feedback from interviews and support conversations.
- Conversion to paid, if pricing is part of the test.
Frequently asked questions
How long does an MVP take?
Many focused SaaS MVPs take between six and twelve weeks, depending on scope and integrations.
No-code or custom code for an MVP?
No-code can be ideal for very early validation. Custom code makes sense when you need specific functionality, performance or a foundation to grow on.
What if the MVP fails?
Then it did its job — you learned cheaply. The data tells you whether to pivot the audience, the problem or the solution.