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. It is the most common way startups die: in CB Insights' analysis of failure post-mortems, 42% built something with no market need (CB Insights). This checklist forces the useful questions first: who it is for, the one job it must do, what "working" looks like, and what you are 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.
How to use this
For each question, answer honestly in one of three ways: yes, and we can prove it, we think so, but we are guessing, or not yet. The "guessing" and "not yet" answers are assumptions, and assumptions are exactly what an MVP exists to test cheaply, before you have spent the runway, not after.
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, even with a worse solution?
- What are they using instead right now, and why does it fall short?
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, on purpose?
- 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 are least sure of?
- Can you test that assumption without building the whole thing?
- What is 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, not just effort?
5. Decide your metrics
- What is the one metric that tells you to double down?
- What result would tell you to pivot, and have you written it down in advance?
- How will you instrument it before launch, not after?
What your answers tell you
If the gaps cluster in validate the problem or riskiest assumption, stop and test before you build anything, because that is precisely the 42% failure mode. If they cluster in the one job or metrics, you have a real idea but a fuzzy experiment, and a fuzzy experiment only ever gives a fuzzy result. Tighten the scope and the success metric first.
When you want a partner to scope and build it fast without over-building, that is what our Accelerator is for, backed by our web development team. Book a call to pressure-test the plan before you commit the budget.