The complete MVP app checklist
Everything to decide before you build a first version — so your MVP proves the right thing instead of burning runway on the wrong one.
Most MVPs fail because they answer a question nobody was asking. This checklist forces the useful questions first: who it's for, the one job it must do, what "working" looks like, and what you're allowed to leave out.
It walks the full path — problem validation, scope, the riskiest assumption, the build-vs-buy calls, and the metrics that tell you whether to double down or pivot.
Run it before you write a line of code, and your MVP becomes an experiment with a clear result, not a small product with a big bill.
1. Validate the problem
- Can you name the specific person who has this problem?
- Have you talked to ten of them — not friends, real prospects?
- Would they pay to make it go away today, with a worse solution?
- What are they using instead right now?
2. Define the one job
- In one sentence: what is the single job your MVP must do?
- If you could ship only one feature, which one proves the idea?
- What are you deliberately leaving out of v1?
- What does "it worked" look like — a number, not a feeling?
3. Find the riskiest assumption
- What has to be true for this to succeed that you're least sure of?
- Can you test that assumption without building the whole thing?
- What's the cheapest experiment that would change your mind?
4. Build vs. buy vs. fake
- Which parts can be off-the-shelf instead of custom?
- What can you do manually behind the scenes before automating it?
- Where is custom engineering actually the differentiator?
5. Decide your metrics
- What's the one metric that tells you to double down?
- What result would tell you to pivot — and have you written it down?
- How will you instrument it before launch, not after?
Answer these and your MVP is an experiment with a clear pass/fail, not a guess with a deadline. Want help scoping it? See the Accelerator or book a call.