The MVP Checklist: 12 Steps to Take Before You Build Anything
Most MVPs don't fail at the code. They fail because nobody decided what v1 was supposed to prove. Work through these 12 steps first and you'll build less, ship sooner, and know what "it worked" means.
Turn my checklist into a PRD — free · Talk it through with us
Why a checklist before code
AI tools can generate an app in an afternoon. That made building before deciding cheaper to make and more expensive to fix. When the idea is fuzzy, the tool fills gaps with guesses. You get a demo that looks finished and a codebase built around assumptions no one agreed to.
A checklist forces who it's for, what it has to prove, and what it leaves out. Those decisions become the spec that keeps later steps aligned whether a person or an AI writes the code.
The 12-point checklist
Work top to bottom. If you can't answer one clearly, stop there. That gap is the most valuable thing this checklist will find.
Part 1. The problem
1. Name one user, specifically
Clinic managers at 5–20 person practices beats healthcare. A market is not a user. Name the person, the size of the place they work, and the job they are in the middle of when the problem shows up.
2. Describe the painful moment and today's workaround
Write the moment it hurts, and what they do instead. The workaround is the real competitor. You are not up against a category. You are up against the texts, the spreadsheet, and the process they already tolerate. The Mom Test is the book on how to ask about that moment so people can't politely lie to you.
3. Before and after in one sentence each
Example before: Swapping a shift takes 14 texts and a spreadsheet. After: A swap is requested and approved in under two minutes. If you cannot write both sentences, v1 is still a direction, not a product.
Part 2. What v1 must prove
4. State the one assumption v1 tests
It is usually this: users will do X instead of their workaround. One assumption. If the first release is testing three bets, you will not know which one failed.
5. One success metric and a threshold
Example: 60% of pilot clinics process at least one swap a week through the app by week four. "Lots of users" and "people like it" are not thresholds. Pick one number and a date.
6. First 5–10 users by name
Write the names. If you can't list them, recruiting is the first milestone, and building is not. This is the step Y Combinator's How to Plan an MVP is known for, and it is where The Mom Test earns its keep: talk to those people about the painful moment, not about your idea.
Part 3. Scope
7. Core workflow as 5–7 steps from first action to moment of value
Start at the first thing the user does and stop at the moment they get the value. If the path needs more than about seven steps, you are describing more than one workflow.
8. Sort features into Now, Later, or Never
Now means the workflow can't complete without it. Login, one role, and one happy path is often enough. Later is real, and it is not this release. Never is how you stop a good idea from becoming scope.
9. Non-goals list
Write what v1 will not do. Examples: No payroll integration. No mobile app. No multi-location. A non-goal you didn't write down will get built anyway, because nobody had permission to leave it out.
Part 4. Ready to build
10. Constraints: budget, deadline, integrations, data sensitivity, compliance
These decide what "done" is allowed to cost and what the product is allowed to touch. A clinic scheduling app that stores staff phone numbers is not the same build as a public to-do list. Decide how much time the first release deserves before you decide what goes in it. Shape Up puts it this way: estimates start with a design and end with a number; appetites start with a number and end with a design.
11. Turn answers into a PRD
The PRD is those decisions written up for the people, or the AI, who build it: problem, user, workflow, v1 scope, non-goals, success metric, acceptance criteria.
12. Technical scope before committing money
Build order, data model, integrations, and risks. This is the document that turns "how long will this take?" into an estimate you can argue with. Write it before you pay anyone to build.
What the best founder advice agrees on
The checklist is not a Codalio invention. It is the overlap of advice that has held up for a decade, now made urgent because AI removed the cost that used to force these decisions.
How to Plan an MVP (Michael Seibel, Y Combinator) is the YC version of steps 4–9: launch quickly, get a handful of real users, timebox the build, write the feature list down and cut it, and don't fall in love with the first version. That is where the "name your first 5–10 users" step comes from.
Shape Up: Set Boundaries (Basecamp) is the source for step 10. "Estimates start with a design and end with a number. Appetites start with a number and end with a design." Decide how much time the first release deserves before you decide what goes in it.
The Mom Test (Rob Fitzpatrick) is the book on how to ask users questions they can't lie to you about. It sits behind step 2, the painful moment, and step 6, the first users.
Copy this checklist
Copy it and fill it in. There is no email gate. If a line stays blank, that blank is the work, not a reason to start building.
12-point MVP checklist
MVP checklist for founders — 12 steps before you build
Work top to bottom. If you can't answer one clearly, stop there. That gap is the most valuable thing this checklist will find.
Part 1 — The problem
1. Name one user, specifically. "Clinic managers at 5–20 person practices" beats "healthcare". If you can't picture them, you can't design for them.
2. Describe the painful moment. When exactly does the problem hit, and what do they do today instead? The workaround is your real competitor.
3. Write the before and after in one sentence each. Before: "Swapping a shift takes 14 texts and a spreadsheet." After: "A swap is requested and approved in under two minutes."
Part 2 — What v1 must prove
4. State the one assumption v1 tests. Usually it's "users will do X instead of their workaround". Everything in v1 should serve that test.
5. Pick one success metric and a threshold. For example: "60% of pilot clinics process at least one swap a week through the app by week four." A number turns opinions into a decision.
6. Decide who your first 5–10 users are, by name. If you can't list them, recruiting is your first milestone, not building.
Part 3 — Scope
7. Write the core workflow as 5–7 steps. From the first action to the moment of value. That path is the MVP. Everything else needs a reason.
8. Sort every feature into Now, Later or Never. Now = the workflow can't complete without it. Be ruthless: login, one role and one happy path is often enough.
9. Write a non-goals list. "No payroll integration. No mobile app. No multi-location." Non-goals stop scope creep before it starts.
Part 4 — Ready to build
10. Name the constraints. Budget, deadline, required integrations, data sensitivity, compliance. These shape the technical choices more than features do.
11. Turn the answers into a PRD. Problem, user, workflow, v1 scope, non-goals, success metric, acceptance criteria.
12. Get a technical scope before you commit money. Build order, data model, integrations and risks.
Worked example: ShiftSwap
ShiftSwap is a fictional example, not a customer. The founder wants an app for clinic staff scheduling. The left column is the fuzzy version. The right column is what the checklist forces.
| Checklist point | Before | After |
|---|---|---|
| User | Healthcare workers | Front-desk and nursing staff at 5–20 person clinics, plus the manager who approves swaps |
| Assumption | People want better scheduling | Staff will request swaps in an app instead of texting the manager |
| Success metric | Lots of users | 60% of 8 pilot clinics run at least one swap a week by week 4 |
| Now | Scheduling, payroll, chat, time-off, mobile app | Post a shift, claim a shift, manager approves, everyone gets notified |
| Non-goals | None listed | No payroll, no native mobile app, no multi-location, no chat |
The after column is a PRD waiting to be written. It's also about a fifth of the original build. See this example written up as a PRD.
Mistakes that waste the first build
Building the roadmap instead of the MVP
More than one primary workflow is two products. v1 gets one path from the first action to the moment of value. Everything else waits.
Success with no number
A metric without a threshold cannot fail, so it cannot teach you anything. "Users are happy" is a mood. "60% of pilot clinics run at least one swap a week by week four" is a result.
Skipping non-goals
If you don't say what is out, the build absorbs the roadmap. Non-goals are the shortest way to keep v1 small.
Letting the tool decide
A prompt-to-app tool builds what it infers. Without a spec, there is nothing to check the output against. The checklist is the raw material. The PRD is the spec.
Why this matters more when an AI builds it
Vibe coding, in Karpathy's original sense, means accepting what the model produces without reading it. Simon Willison's line is that reviewing, testing and being able to explain the code is what turns that into software development. The checklist is the founder's version of that discipline: you may not read the code, but you can hold it to a written intent.
Addy Osmani lists spec-first design and testable requirements as the practices that separate vibe coding from AI-assisted engineering. "AI tools are copilots, not autopilots."
A tool builds what it is told. A checklist is how a non-technical founder decides what to tell it, and how they know afterwards whether it did.
Codalio Blueprint
The checklist gives you decisions. Codalio Blueprint is a free, open-source add-on for AI coding tools that turns them into a written plan: /prd-builder interviews you and writes the PRD into docs/prd/, and /mvp-checklist produces the deeper cut list and v1 done-criteria. Two commands to install in Claude Code (/plugin marketplace add codalio/codalio-blueprint, then /plugin install codalio-blueprint@codalio-blueprint); a few clicks in Cursor's plugin browser. When you want the plan carried through to production code you own, that is what Codalio itself does.
Paste this into your coding tool
These work in Claude Code, Cursor, Codex CLI, Gemini CLI and Antigravity. The plain-prompt ones also work in Lovable, Replit and Bolt chat.
Snippet 1 — Run the checklist as an interview (any AI tool).
Act as an experienced product lead. Interview me one question at a time to complete this MVP checklist. After each answer, push back once if it is vague, then move on. Do not suggest features. At the end, print my answers as a table with columns Step, Answer, Confidence (High/Medium/Low), and list the three lowest-confidence items as "go talk to users about this first".
The 12 steps: 1 one specific user; 2 the painful moment and today's workaround; 3 before/after in one sentence each; 4 the single assumption v1 tests; 5 one success metric with a threshold and a date; 6 the first 5–10 users by name; 7 the core workflow in 5–7 steps; 8 every feature sorted Now/Later/Never; 9 a non-goals list; 10 constraints (budget, deadline, integrations, data sensitivity, compliance); 11 what the PRD will contain; 12 what the technical scope must answer before money is committed.
Snippet 2 — Cut list (paste your feature list underneath).
Here is my feature list for v1. For each item, answer: which step of the core workflow does it serve? If none, move it to "Later" or "Never". Then rewrite the list as Now / Later / Never with one-line reasons. Be ruthless: v1 must complete one workflow end to end and nothing else.
Snippet 3 — With Blueprint installed.
/mvp-checklist
Here are my checklist answers: [paste the table from Snippet 1]. Produce the cut list and the v1 done-criteria.
Snippet 4 — A rule for your tool's memory file (CLAUDE.md, AGENTS.md, .cursor/rules, or Lovable's Project Knowledge):
Project rule: v1 scope is defined in docs/mvp-checklist.md. Before adding any feature, check whether it appears under "Now". If it does not, stop and ask me instead of building it.
Frequently asked questions
How long should an MVP checklist take?
An afternoon for a founder who knows the problem well. If a point takes days, that's a real unknown, and you should talk to users before you build.
What's the difference between an MVP checklist and a PRD?
The checklist is the decisions. The PRD is those decisions written up for the people, or AI, who build it: workflow, scope, acceptance criteria. Do the checklist first. How to Write a PRD for an MVP.
How many features should an MVP have?
As few as it takes to complete one core workflow end to end. If the list is past a handful, check whether it's really one workflow.
Do I still need an MVP checklist if I'm using an AI app builder?
More than ever. AI builds what you describe. A vague idea produces confident, wrong software faster.
Should an MVP be production-quality?
Scope should be minimal, but what you ship should be real. Real users mean real data, so security and code you can keep building on still matter. Source Code Ownership.
What comes after the checklist?
A PRD, then a technical scope, then the build. Technical Scope Template.
Related
- How to Write a PRD for an MVP — turn these 12 answers into a spec.
- Technical Scope Template — build order, data model, and risks before you commit money.
- AI MVP Builder — how Codalio takes a feature from spec to code.
Turn these 12 answers into a PRD
The checklist is the decisions. Codalio drafts the PRD from a feature description, then a technical spec and production-grade code you own.