In this guide 6 sections
An MVP moves through six stages: frame the one question, draw the scope line, design the core journey, build it, launch to a small pilot, and read the evidence. Each stage ends with a decision you make, backed by something the builder hands you in writing.
Stage one frames a single question
Every first version exists to answer one question, such as whether clinic owners will pay to replace their appointment diary or whether dispatchers will accept a shared load board. Write it so a stranger could say yes or no.
Your side supplies the assumptions list: who the buyer is, what they use today, what they would pay and what would make them refuse. Write it before any screen is drawn. In return comes a risk register ranking each assumption by how badly the product dies if it is wrong. Short and blunt.
The stage ends when you pick the riskiest assumption to test. Everything after serves that choice.
- The one question, written as yes or no
- Named buyer and named user, who may differ
- Today’s substitute: spreadsheet, WhatsApp group, paper register
- The result that would make you stop
Stage two draws the scope line
Scope is a list with two columns, what ships and what waits. Anything that does not help answer the question goes into the waiting column, however reasonable it sounds. Reports, bulk import, role editors and settings screens usually wait.
Start from the features you believe are essential. A scope sheet comes back with each one marked in or out, plus a reason, and you should argue with the reasons because the list follows from them.
Sign off here means you accept that the first version will feel thin. That is intended.
Stages three and four design and build one journey
Pick the single path a user takes from arrival to the moment of value. Sketch each screen as a wireframe, click through it on a phone, and only then build. A booking app might run sign-up, choose a slot, confirm, receive a reminder.
Supply real sample data and your brand basics. A clickable prototype arrives first, then a working build on a test address you can open yourself on any phone, and you should check it weekly. Never wait for the end.
Resist adding a second journey mid-build, because each addition moves the pilot date and blurs the question you started with.
- Wireframes approved before any code
- Test address with sample records
- Weekly working demo, not slides
- A written list of known gaps
Stage five puts it in front of a small pilot
A pilot is a controlled release to a handful of real users, often ten to thirty, whom you invite yourself. Give each a named contact for problems. Fix the end date in advance.
Provide the invite list, access rules and a feedback route. Expect a launch checklist covering hosting, backups, error alerts and a way to switch a single user off without touching the others. Someone must watch the alerts daily in week one.
Stage five ends when the pilot window closes. It does not end when the app feels finished.
Stage six reads the evidence and decides
Go back to the question from stage one and count how many pilot users completed the core journey, returned unprompted, paid or agreed to pay, and which assumptions held. Read the comments, but weigh behaviour above praise.
The read-out lists usage logs, feedback themes, defects found and a proposed plan for the next phase. Then you choose one of three paths. Continue, change direction or stop.
Book the read-out meeting before the pilot starts, so the decision date does not drift into the following quarter while everyone is busy.
MVP stage tracker
A one-page table with six rows, one per stage. Columns are what you hand over, what the builder hands back, the decision, the owner’s name and the date due. A seventh strip at the bottom holds the original yes or no question so every review starts from it.
Open a blank worksheet to printQuestions owners ask
Who should own the decision at the end of each stage?
One named person from your side, usually the founder or business head. Committees slow stages down. The builder advises, but the decision to move on sits with the person who carries the business risk.
Can two stages run at the same time?
Design and build can overlap for separate screens. Framing and scope should not. Building before the scope line exists is how first versions swell into half-finished products.
What if the pilot evidence is unclear?
Extend the pilot with a sharper question, or recruit users who match the buyer more closely. Unclear evidence usually means the wrong users were invited or the question was too wide.