The two options at a glance
| SaaS MVP | Full product build | |
|---|---|---|
| Purpose | Learn whether customers want this, and what they use | Deliver a product that customers are already waiting for |
| Scope | One core job done well, for one kind of customer | The breadth a paying market expects |
| Main risk it addresses | Building something nobody wants | Arriving late or incomplete in a market that exists |
| Investment | Smaller, and staged | Larger, and committed earlier |
| What follows | A decision to extend, change or stop | Operation, support and steady improvement |
| Typical owner | Founders close to the first customers | A product team with a roadmap |
Decide by what is still unproven
Every new product carries two kinds of risk. Market risk is the chance that people will not want it or will not pay. Delivery risk is the chance that you cannot build and run it well. An MVP is a tool for market risk. A full build makes sense when market risk is already low.
| Evidence you have | What it means | Sensible route |
|---|---|---|
| An idea and your own conviction | Market risk is high | Interviews and a prototype first, then an MVP |
| Interviews that confirm the problem | People have the problem. Whether they pay is open | MVP, with payment in it |
| A waiting list or pilot customers | Demand exists for something | MVP shaped with those customers |
| Signed contracts or letters of intent | Demand is proven for a defined scope | Build to that scope, in stages |
| An existing product with customers that you are rebuilding | Demand is proven, and expectations are set | Full build, released in increments |
When each one fits
Choose an MVP when
- You have not yet seen customers pay or commit
- You are entering a new market or a new kind of customer
- Funds are limited and must last through learning
- You expect the product to change as you learn
- You need something real to show investors or early customers
Choose a full build when
- Customers have committed to a defined scope
- You are replacing a product that people already rely on
- Buyers will compare you with established competitors on features
- Enterprise or regulated customers require security and compliance work from the first day
- The cost of launching too thin is losing the market's trust
What a SaaS MVP must not skip
Small scope is the point of an MVP. Low quality is not. Some foundations are cheap to lay at the start and expensive to add after customers arrive.
Foundations of a SaaS MVP
0 of 7 checkedWhat you can leave out is breadth. Admin screens can be basic, reports can be exports, and rare cases can be handled by hand until volume justifies building them.
How an MVP becomes the full product
- 01
Launch to a small group
Real customers, close enough that you can talk to them.
- 02
Measure against what you set beforehand
Whether they complete the core job, whether they return and whether they pay.
- 03
Decide
Extend what is used, change what is not, or stop if the core assumption failed.
- 04
Harden as you grow
Add the breadth, the admin tools and the scale work in the order customers force them.
If the foundations above are in place, the MVP is extended, not thrown away. If they were skipped to save time, part of it will be rebuilt, and it is better to know that when you choose.
A worked example
Two founders, the same idea, different evidence
Both companies are invented. Each wants to build scheduling software for clinics.
- Founder AHas spoken with ten clinics that complain about scheduling. None has agreed to pay.
- Her routeAn MVP for one kind of clinic. Booking, reminders and payment only. Three pilot clinics, with a decision point after the first cycle.
- Founder BRuns a clinic group that has outgrown its current software and has two partner groups who have signed to adopt a replacement.
- His routeA fuller build to a defined scope, since the customers and their requirements already exist. Released in stages so that each group can move over.
The idea is the same. The evidence differs, and so does the right way to build.
What to do next
Write down what you already know about demand and what you are still assuming. If the assumptions are the bigger list, plan an MVP. Our guide on planning a mobile app MVP shows how to cut a feature list, and most of it applies to web products as well.
Our startup MVP development and SaaS development pages explain how we build each. If you are between the two, tell us what evidence you have and we will say which route we would take.
Common questions
Will investors take an MVP seriously?
Investors generally look for evidence that customers want the product. A small product with real use and real payment is stronger evidence than a large product with neither. What weakens an MVP in their eyes is not its size. It is the absence of users, or shortcuts that would make it unsafe to grow.
How small can an MVP be?
As small as one complete job for one kind of customer, including whatever is needed to run it safely. If a user cannot get from sign-up to the result without your help, it is too small. If it includes features nobody has asked for, it is too large.
Do we have to rebuild the MVP later?
Not if it was built on sound foundations. Data separation, a considered data model, automated deployment and clean code let you extend an MVP into the product. A rebuild is needed when those were skipped, or when what you learn changes the product so much that little of the original applies.
What if a competitor launches a fuller product first?
Then you learn from their launch at no cost. Being first with a broad product matters less than being right about what customers will pay for. If the market is clearly proven and moving fast, that is evidence in favor of a fuller build, which is the case this page describes.