How to Build an MVP: A Step-by-Step Guide
To build an MVP, start from your validation evidence, define the single journey a user must complete to get the core outcome, build only what that journey needs using the cheapest method that works, and decide in advance which metric will tell you whether it succeeded.
By Javier Alonso, Founder & CEO. Updated .
Step by step
Start from what you have validated
Write down the customer, the problem and the promise your validation supports. The MVP exists to test that promise, not your full vision.
Write the one question the MVP must answer
For example: "Will clinic managers use automatic reminders every week if setup takes under ten minutes?" A clear question makes scoping decisions easy.
Map the single success path
List the steps a user takes from first visit to receiving the core outcome. Everything not on that path, such as settings, admin panels and secondary features, can wait.
Choose the cheapest way to deliver it
Decide which steps need software and which can be manual, no-code or faked behind the scenes. See no-code vs code.
Set the success metric and threshold
Pick one metric tied to your question, such as weekly active use, completed tasks or payment, and the number that means continue. Write it down before launch.
Ship to a small group and talk to them
Launch to 10 to 50 people who match your ICP. Watch how they use it, interview them and fix what blocks the success path.
How much to build
A practical test for every feature: does it help a user reach the core outcome, or help you measure whether they did? If neither, cut it. Most MVPs end up with three to five essential capabilities. The feature prioritization guide gives a method for deciding.
How long it should take
Aim for weeks, not months. If your plan runs past two or three months, there is usually a cheaper MVP type that answers the same question, such as a concierge version or a single-feature build.
Example
A founder validating a tool that writes weekly social posts for independent gyms decides the MVP must answer: "Will gym owners publish posts we draft from their class schedule at least three weeks in a row?" The success path is: connect the schedule, receive drafts, approve and publish. She builds schedule import and draft generation, and handles publishing by hand for the first 20 gyms. The metric is the share of gyms publishing three weeks running. The target is 50%.
Common mistakes
- Building for every possible customer instead of one ICP.
- Polishing design before the success path works.
- Launching publicly before a small group has used it.
- Treating the MVP as version one of the final architecture. It is fine to rebuild later.
For your role
- Builders
- If you have an idea but no evidence yet, validate before you build. The MVP is the second experiment, not the first.
- Mentors
- Ask founders to state the MVP's question and success threshold. Scope creep usually starts when those are missing.
Primary sources
- Practical Design: MVP Spec — Y Combinator
- Principles — The Lean Startup
Common questions
- What should an MVP include?
- Only what one target customer needs to reach the core outcome, plus what you need to measure whether they did.
- What should not be in an MVP?
- Admin polish, settings for edge cases, broad integrations and secondary workflows, unless the core outcome cannot be delivered without them.
- Should I build manually before building software?
- Often, yes. Delivering the outcome by hand to the first customers proves the workflow before you invest in automating it.
Put it into practice
MVP Builder generates a working MVP from a description and lets you iterate with a live preview.