Should you build the whole thing, or start with an MVP?
An MVP is the smallest version of a system your team can use for real work: live on real data, doing one core job properly from day one. It is the right place to start when the budget is small, the scope is still unclear, the timing is tight, or the people asking for it are still working out what they want. Scope more up front when everyone starts on a fixed date, or when the data has to be right from the first day.
On this page
Key takeaways
- An MVP is the smallest version of a system your team can use for real work, live on real data and doing one core job properly.
- Start with one when the budget is small, the scope is unclear or the timing is tight. Scope more up front when it must be right on a fixed date or handles sensitive data.
- The hard part is deciding what goes in. The MVP scoping worksheet below turns that into seven lines you agree before anything is built.
Most of my proposals mention an MVP somewhere, and I've noticed the word means quite different things depending on who is reading it. For some people it sounds like a cheaper, unfinished version of what they asked for, for others it's a vague promise that the proper system will come later, and it gets mixed up with a pilot more often than you'd think.
So this is how I think about it in implementation projects. An MVP is the right call for teams with a small budget, for projects where the scope and effort are still unclear, for anything time sensitive, and for stakeholders who are less technical and still working out what they want, which is completely normal. In all of those situations, agreeing on the smallest version a team can use for real work, getting it live in days or weeks and then letting the people using it shape what comes next gives everyone something real to react to before the bigger decisions get made.
The hardest part is deciding what goes into that first version. The tool I use for that conversation is the MVP scoping worksheet: seven short lines, written down and agreed before anyone builds anything.
So what is an MVP?
The smallest version of a system your team can use for real work, live on real data and doing one core job properly from day one.
- Minimum Only what the core job needs.
- Viable Good enough that people use it and trust it.
- Product The system your team runs, like a CRM, a survey programme or an automation.
It's different from a pilot
An MVP decides what gets built, and a pilot decides who uses it first. You can pilot an MVP with one team before rolling it out more widely.
Why not just build the whole thing?
You can, and both routes can end with the full system. The second one lets you learn what it should look like while your team is already using it.
All at once
- Scope it all up front
- Build for months
- Launch to everyone
- Find out what was missed
With an MVP My default
- Scope the core job
- Build it in days or weeks
- Use it for real work
- Add what's needed next, and repeat
The difference is when you find out what you missed. With a full build you find out at launch, after the money is spent and everyone has been told it is ready. With an MVP you find out in the first weeks, while changing course is still cheap.
How do you tell whether you need an MVP or a fuller scope?
Five questions are worth asking before you decide. I'd answer them with the people who will use the system in the room, since the person who commissioned it often sees only part of the picture.
- How big is the budget? A small one points to an MVP, because it puts the money into one job done well instead of spreading it thinly across features nobody has tested. Small budget: start with an MVP
- How clear is the scope? If the scope and effort are still unclear, build the smallest useful version first and let it show you the real size of the work. If the scope is written down and agreed by everyone who will use it, a fuller scope up front carries much less risk. Unclear: start with an MVP
- How tight is the deadline? A first version can be live in days or weeks while a full build usually takes months. Time sensitive: start with an MVP
- How technical are the people asking for it? If they are still working out what they want, which is completely normal, something real in front of them will teach everyone more than another round of requirements meetings. Still deciding: start with an MVP
- Does it have to be right on a fixed date, or handle sensitive data? This is the one that overrides the rest. Yes: scope more up front
When to scope more up front
If everyone starts using it on a fixed date, or it handles sensitive data that has to be right from the first day, scope more before building, whatever the other four answers say. If most of your answers point to an MVP and the fifth does not apply, start with one.
If you cannot yet tell which process deserves a first version at all, that is a different problem, and a business process maturity assessment is the better first step. It gives you a roadmap rather than a build, and the MVP comes after it.
What do people get wrong about MVPs?
Three misunderstandings come up again and again, and each one can sink a project that was well planned in every other way.
Treating it as a cheaper, unfinished version
An MVP has fewer features than the full system, and it has the same standard for what it does include. The first version has to be good enough that people use it and trust it, because a rough tool gets abandoned and the team learns nothing from it. What you cut is features, and what you keep is accuracy, a sound data structure and a clear owner for every piece of it.
Treating it as a vague promise that the real system comes later
If "phase two" is only an idea in someone's head, it tends not to happen. A first version needs a written list of what was left out, a number that shows whether it is working, and a date on which someone decides what comes next. Without those three, the MVP is simply a smaller project with no ending.
Confusing it with a pilot or a proof of concept
An MVP decides what gets built. A pilot decides who uses it first, and you can pilot an MVP with one team before rolling it out more widely. A proof of concept answers a narrower question, whether something can be done at all, and it is often a throwaway that nobody uses for real work. An MVP is the opposite, since it is live on real data from the start.
What you cut is features. What you keep is accuracy, a sound data structure and a clear owner for every piece of it.
Klara Condac
Defining your MVP in four steps
Start with one outcome
Write down the one thing that should be true once it's live, and the number that will tell you it's working. For example: "Every new request lands in one place and gets assigned automatically."
Split must-haves from nice-to-haves
For each feature, ask whether the team could do the core job on day one without it. If they could, it goes on a phase two list, so it stays visible as a decision for later.
Set up the foundation properly
Features can be minimal, but the data structure, naming and who owns what should be set up well from the start. These are the hardest things to change once people are using the system.
Test with real people and real data
Map how the process works today, then put the first version in front of the people who'll use it, with their own records. Dummy data and the documented process tend to hide the problems that matter.
What goes in an MVP scoping worksheet?
The MVP scoping worksheet is the four steps above turned into a document with seven lines, which you fill in and agree with the people involved before anything is built. Tick each line once it is agreed, or copy the whole sheet into your own document.
Your ticks are saved in this browser only. Nothing is sent anywhere.
Where to spend the time
Lines three and five deserve the most time, since a feature the team can do without on day one belongs on the phase two list and a foundation decision made badly is the most expensive thing to fix later.
The worksheet doesn't tell you what to build, because that depends on your data, your constraints and your budget, and working that out is a conversation worth having with someone who has seen it before. The same thinking applies outside systems: a first customer survey can be small and still go to real customers and feed a real decision, which is the idea behind the guide to customer experience survey pitfalls.
Two everyday examples
What would the MVP be for a monthly report?
A team spends hours each month copying numbers from a few systems into slides.
In the MVP First version
- Data pulled from the main source automatically
- The handful of numbers people check most
- One dashboard that refreshes itself
Later Phase two
- More data sources
- Filters by team or region
- Scheduled emails
How to measure it. Hours spent on the report each month.
And for a manual queue in an ops team?
Requests arrive by email, chat and spreadsheet, and someone spends part of every day sorting and chasing them.
In the MVP First version
- One form for every request
- One shared list with a status for each
- Simple rules that assign the right person
Later Phase two
- Automatic sorting by priority
- Updates sent to the requester
- A dashboard of turnaround times
How to measure it. Average time from request to done.
From the work
Most of my implementation projects start this way, and two of the systems on this site show what a focused first version can look like.
For a US research organisation managing about 9,000 US towns: from brief to fully deployed in under a week, with a web application, a repeatable data model and a dashboard the team now uses to produce reports in minutes.
Read the case study Case study Personalized learning plans, automatedFor a US nonprofit, one job from start to finish: a teacher fills in one short form and receives a grade-specific plan within minutes, with no logins and no manual work behind it.
Read the case studyBoth were built around a single clear job on the team's real process, and both were set up to grow afterwards. The research team owns a system it can extend as the programme grows, and the learning plans system takes new grade levels and plan variations by extending its template library and matching rules, with nothing changing for teachers. That is the foundation point from step three in practice.
Questions people ask
What is the difference between an MVP, a pilot and a proof of concept?
An MVP decides what gets built: the smallest version of a system a team can use for real work. A pilot decides who uses it first, so you can pilot an MVP with one team before rolling it out more widely. A proof of concept only tests whether something can be done at all, and it is often thrown away afterwards, whereas an MVP is live on real data from the start.
How long does it take to build an MVP?
Days or weeks rather than months, because it does one core job and nothing more. The time goes into agreeing what that job is and setting up the foundation properly, not into building features. One system on this site, a custom research platform, went from brief to fully deployed in under a week.
What if the system has to be right on day one?
Then scope more up front. If everyone starts using it on a fixed date, or it handles sensitive data that has to be correct from the first day, an MVP is not the right call. Both routes can end with the full system; the MVP route is for when you can afford to learn while the team is already using it.
What happens to the MVP when the full system comes?
In most projects it becomes the first part of the full system, because the data structure, naming and ownership were set up properly from the start and the phase two list is added one item at a time. The exception is when the first weeks show that the original idea was wrong, in which case you have found that out cheaply, and the lessons carry over even if the build does not.
Who should decide what goes into the MVP?
The person who owns the outcome, together with the people who will use the system every day, with whoever builds it advising on effort. The question to put to the room for each feature is whether the team could do the core job on day one without it, which gives everyone the same test instead of leaving the decision to whoever argues hardest.
More resources
A note from me
Scoping a project and want a second opinion on what the first version should include?
Most of my implementation projects start with an MVP, and scoping it well is where I spend a lot of my time. Tell me what you are trying to get live.