Checklist · MVP readiness checklist
MVP Readiness Calculator
Twelve yes/no questions across Problem clarity, Customer clarity, Riskiest assumption and Validation plan tell you whether you are ready to build — or still need to do the work. Free, no signup, no AI.
Twelve yes/no questions
Answer honestly. Each “no” is a gap to close before building.
Score
You do not have enough clarity yet to invest in building. Spend the next 7 days on the weakest bucket below.
−40 penalty for 4 buckets below 50%.
Per-bucket breakdown
Biggest gap
Problem clarity
Problem clarity is your weakest bucket. Spend a week observing the problem in the wild — sit beside three customers, watch what they do. Resist the urge to talk about your solution.
Methodology
How the score is calculated
Twelve yes/no questions, four buckets of three, with a penalty for any bucket that is half-empty. The penalty is the whole point.
The base score is the percentage of yeses across all twelve questions. The bucket score is the percentage of yeses within that bucket. Any bucket below 50 percent costs you 10 points off the total.
- base = yeses ÷ 12 × 100
- penalty = 10 per bucket where bucket_score < 50%
- total = max(0, base − penalty)
The penalty is intentionally aggressive. A score of 50 with uniform yeses across all buckets is a much stronger position than 50 with two perfect buckets and two empty ones. The penalty makes the math reflect that.
The output bands: 0–39 not ready (you do not have enough clarity yet); 40–59 gaps remain (real signal but uneven foundations); 60–79 almost there (one more focused round and you are ready); 80+ ready to ship a test (foundations in place).
Framework
What each bucket actually measures
- Problem clarity
- You can write the problem in one specific sentence, you have observed it in the wild, and you know the smallest unit of customer who has it. Without this you are building based on assumptions, not observations.
- Customer clarity
- You can name five specific real people, you can reach them without paid ads, and they already pay for adjacent solutions today. If you cannot reach them cheaply, the unit economics will not work even if the product is great.
- Riskiest assumption
- You have named the sentence that, if false, kills the idea. You have designed a test that could falsify it. You can run that test without writing production code. This is what separates founders who validate from founders who rationalize.
- Validation plan
- You have the next five customer conversations on your calendar, a falsifiable success metric with a number, and a date for kill-or-continue. Without these, validation drifts.
Worked example
A realistic readiness scenario
The idea
Async onboarding for fully remote teams: a structured 30-day buddy programme that runs entirely in Slack and Notion.
3/3 yes. Specific sentence, observed at three companies, knows it is a Head-of-People problem.
2/3 yes. Has five names and can reach them — but adjacent paid solutions are unclear.
1/3 yes. Named the assumption (people will follow a structured async programme), but no test designed and no plan to run it without code.
1/3 yes. Has interviews scheduled, but no metric, no deadline.
Total
38 / 100 — Not ready
Base 58, −20 penalty for two buckets below 50%.
Weakest bucket
Riskiest assumption. The founder knows the sentence but has not designed a test for it.
Suggested next experiment
Run a manual buddy programme for two real teams next week, all in existing Slack channels. The success metric: do at least 60% of pairs complete the 30-day cadence without a nudge from you? That is a no-code-required falsifiable test of the riskiest assumption.
Recommended next actions
What to do with your readiness score
Below 40
Stop and observe
Spend a week observing the problem in the wild. Sit beside three customers; do not pitch your solution. Re-run the calculator afterwards.
40 to 59
Close one bucket at a time
Pick the lowest bucket and spend a focused week on its three questions. Re-run weekly until every bucket is at 67% or higher.
60 to 79
Design the falsification test
If Riskiest assumption is your gap, write the killer sentence and design the seven-day test today. If Validation plan is the gap, get the calendar invitations sent.
80 plus
Run the test, not the meeting
Stop preparing and start testing. The score is high enough that the next planning session is procrastination.
FAQ
Frequently asked questions
What does MVP-ready actually mean?
It does not mean "the design is ready" or "the spec is written." MVP-ready means: you have a specific problem statement, you can name the customers who have it and reach them, you have identified the assumption that would kill the idea if it were false, and you have a plan to test that assumption — ideally without writing production code.
Can I be MVP-ready without writing code?
Yes, and you should aim to be. The riskiest assumption can usually be tested with a landing page, a manual concierge offering, or a prototype JSON. Code only becomes the right move once a non-code test has produced a real demand signal you can defend.
What if I score 40?
You are in "gaps remain" — there is signal but the foundations are uneven. Look at the per-bucket breakdown, find the lowest bucket, and spend the next week closing it. A bucket below 50 percent costs you a 10-point penalty on the total — those penalties are designed to keep you honest, because uneven preparation collapses early-stage projects faster than uniformly-medium preparation.
Why do you penalize buckets below 50 percent?
Because building on a weak bucket is more dangerous than not building at all. Having a beautiful problem statement (Problem clarity 100) but no idea who the customer is (Customer clarity 0) is a worse position than knowing you have work to do everywhere. The penalty pulls the total down to reflect reality.
How do I close the riskiest-assumption bucket?
Write down the sentence that, if false, kills the idea. Most founders cannot write this sentence on demand — that is the gap. Once you have it, design the cheapest test that could prove it false within seven days. If your test takes a quarter to run, the assumption is still abstract; force yourself to a one-week test.
Can this replace a PRD?
No, but it should come before one. The MVP Readiness Calculator answers "should we be writing a PRD at all?" If the score is low, the PRD will be premature. If the score is high, the PRD will be much shorter — most of the answers are already in the calculator.
How does this fit with lean startup thinking?
It is a checklist for the "validated learning" phase before the build phase. Lean startup is famously thin on what to do during validation; the four buckets in this calculator are an opinionated answer.
What is a good MVP success metric?
Specific, falsifiable, and number-bearing. "Ten people pre-pay $50 for the alpha" is a good metric. "Customers love it" is not. The Validation plan bucket asks for exactly this — if you cannot write the metric down, you do not have one.
What does MVP-ready actually mean?
Can I be MVP-ready without writing code?
What if I score 40?
Why do you penalize buckets below 50 percent?
How do I close the riskiest-assumption bucket?
Can this replace a PRD?
How does this fit with lean startup thinking?
What is a good MVP success metric?
Continue your validation
Pair this with one of these
Get early access
Plan the smallest test that closes your weakest bucket.
Kavon Studio takes the gap from this calculator and produces a concrete experiment — landing test, concierge MVP, or interactive prototype — with a falsifiable success metric.
- AI-generated experiments tied to your riskiest assumption.
- Auto-generated landing pages and interactive prototypes.
- Track every test to a decision memo, not just a feeling.