The MVP development process has seven steps: define the problem, scope the first version, prototype, test with users, build, launch, and learn from customers. Each step exists to answer a question as cheaply as possible, so the expensive work only starts once the cheaper tests have passed.
Here's what happens at each step, what you should have at the end of it, and where projects most often go wrong.
Step 1: What problem are you solving, and for whom?
Start by writing down who the customer is and what problem costs them time or money today. Talk to at least a handful of people who have it, and ask how they deal with it now, not whether they'd buy your idea. People are polite about ideas and honest about their own week.
You should finish with: one sentence naming the customer, the job and the result, and evidence that the problem is real. The most common mistake here is skipping this step because the idea feels obvious.
Step 2: What is the smallest version worth building?
Scope the first version by cutting everything a customer doesn't need to finish one job and pay for it. Write out what's included, and just as importantly what's excluded. This is also when the main architecture decisions get made, such as how customer data is separated.
You should finish with: a written scope, a timeline, and a list of exclusions. We go through how to choose in MVP features: what goes in the first version. Check whether anything is technically unproven at this stage too, because that's the one case for a proof of concept.
Step 3: What should the prototype show?
The prototype should show the core workflow, as a clickable design real people can try. It doesn't need every screen, only the path from sign-up to the result the customer is paying for. Keep it in a design tool, where changes take minutes.
You should finish with: a clickable prototype of the one workflow that matters, ready to put in front of people.
Step 4: How do you test with users?
Watch five or six people who have the problem try the prototype, without helping them. Ask them to complete the task and to think aloud as they go. Where they hesitate tells you more than what they say afterwards.
You should finish with: a short list of changes and a settled design. The common mistake here is asking "would you use this?", because people say yes to be kind. Ask what they'd do next, and whether they'd pay.
Step 5: How does the build work?
The build runs in short sprints, each ending in something you can use. Two weeks is a good length: long enough to finish something real, short enough to catch a wrong turn. Foundations such as accounts, data separation and billing come first, then the core workflow.
Three habits keep a build healthy:
- A staging site that updates as work lands, so you always see the real state of the product.
- A demo at the end of every sprint.
- A rule that new ideas go on the "later" list, and anything added must replace something of equal size.
You should finish with: a working product on staging, tested end to end. For a SaaS product, this stage is usually about six weeks of an eight to twelve week project.
Step 6: How do you launch an MVP?
Launch to a small group first, not everyone at once. Your first customers should be people you can talk to directly, and you should expect to fix things quickly. Before going live, check that payments work with real cards, that errors reach you, and that backups can actually be restored.
You should finish with: paying customers, monitoring in place, and someone responsible for responding when something breaks. All our builds include 30 days of support after launch for this reason.
Step 7: What do you do after launch?
After launch, stop adding features for a moment and watch what customers do. Which parts do they use? Where do they get stuck? Who comes back, and who leaves? Then talk to them. Your "later" list gets reordered by real behaviour, and most of the items on it turn out not to matter.
You should finish with: evidence for what to build next. This is the point of the whole process. An MVP isn't the finish line, it's what turns guesses into information.
Where does the MVP process usually go wrong?
MVP projects usually go wrong by skipping the cheap tests, letting the scope grow, or stopping at launch. These five mistakes come up most often:
- Building before testing. Steps 1 to 4 are cheap, and they're the ones that get skipped.
- Scope growth. New ideas slip in during the build, and the date goes with them.
- Treating the MVP as a throwaway. Cutting corners on data separation or billing means rewriting the product later.
- Launching to everyone at once. Early customers need attention you can't give to a crowd.
- Stopping at launch. The first version only pays off if you act on what it teaches you.
How long does the MVP process take?
Steps 1 to 4 usually take a few weeks and can run alongside other work. Steps 5 and 6 typically take eight to twelve weeks for a SaaS product when run with a focused team, including the scoping and prototype stages in our own process. The learning in step 7 never really stops. For timelines by type of product, and what makes a build run long, see how long it takes to build an MVP.
To see how this runs in practice, including what a fixed price covers, read about our SaaS MVP development services and how we price them. If you're at step 1 or 2 and want a second opinion, contact us to get started.
Common questions
What are the stages of MVP development?
The usual stages are research, scoping, prototyping, user testing, building, launching and learning from customers. Teams name them differently, but the order matters more than the labels. Each stage should cheaply answer one question before you pay for the next, more expensive stage.
Who is involved in building an MVP?
Usually a product lead or founder who makes decisions, a designer, one or two engineers covering frontend and backend, and someone responsible for infrastructure, often one of the engineers. Small teams work best at this stage. A founder should stay closely involved, because the product decisions can't be delegated.
Does an MVP need a project manager?
It needs someone doing that job, but not always a dedicated person. On a small build, the lead engineer or founder can keep the scope, the sprint plan and the demos on track. What matters is that one named person is responsible for the date and the exclusions.
What comes first, design or development?
Design comes first for the core workflow, because changing a prototype takes minutes and changing built software takes days. Development of foundations such as accounts and data separation can begin alongside it. The two then run together, with design answering questions as the build raises them.
Want something like this built and run in your own accounts? That's what our SaaS Development service does. You can also see everything we build or look through our case studies.
