Practical reference
Startup Validation Checklist — Before You Build
Nine sections, thirty-plus concrete checks you can run before writing a line of code. Free, no signup, copy-friendly.
Last updated · August 19, 2026
Quick answer
What is a startup validation checklist?
A startup validation checklist is a structured list of evidence-gathering checks you run before writing a line of code. It covers nine areas — problem, customer, solution, market, distribution, willingness to pay, product-market fit, MVP, and problem-solution fit — and turns each into three to five yes/no questions you can answer in a week. The output is not a score or a verdict; it is a list of which assumptions you have evidence for and which you still need to test. Use it to identify the single riskiest unknown in your plan, then run the cheapest experiment that tests it.
Key takeaways
How to use this checklist
- Validation is evidence gathering, not prediction. The checklist turns polite conversations and best-guess assumptions into named yes/no questions you can answer with real customers and real commitments.
- Nine sections, run in order: problem → customer → solution → market → distribution → willingness to pay → product-market fit → MVP → problem-solution fit. Each one builds on the answer to the previous.
- Three to five checks per section. Each check is something a solo founder can answer in a week without writing code. If you cannot answer it, that is the assumption worth testing first.
- The output is not a score, a verdict, or a guarantee. The output is the list of which assumptions you have evidence for and which you still need to test.
- Use the checklist to find the single riskiest unknown in your plan — the one whose failure would invalidate the rest — then run the cheapest experiment that tests it.
How to use it
How to Use This Checklist
Do not answer all nine sections in one sitting. The checklist works best as a loop: pick the assumption that would kill the idea fastest if it were wrong, test that one, then come back and re-read the sections your new evidence changed.
Start with the problem
Before anything else, write the problem down as a sentence someone else could disagree with. If you cannot state who is hurting and how often, the remaining eight sections have nothing to attach to.
Identify the target customer
Narrow until you can name where to find ten of them this week. "Small businesses" is not a customer; "solo bookkeepers who bill hourly" is a group you can go talk to.
Test the strongest assumptions first
Rank your assumptions by how much of the plan collapses if each one is false, not by how easy each is to test. The riskiest assumption is usually that anyone will pay, or that you can reach the customer at all.
Collect evidence, not opinions
Write down what actually happened — what someone did, paid, or committed to — rather than what they said they might do. See the evidence hierarchy below for what counts.
Decide what to validate next
End every pass with one named next experiment and a date. A checklist that produces reading but no next test has not done its job.
The checklist
Nine sections, thirty-plus checks
Run them in order. Each section builds on the answer to the previous one. Stop and test the first section where the answer is no.
Section 1 · Problem
Is the problem real?
Before you check the customer or the solution, check that the problem itself is real. A common failure mode is to skip this step because the founder feels the pain personally — but the founder is one person, not a market.
- Can you name the specific person who experiences this problem, in one sentence? ("Busy parents" is not specific. "Working parents with two kids under five who cook at home four nights a week" is.)
- Does the problem repeat on a regular cadence (daily, weekly, monthly)? Problems that recur are easier to monetise than one-time annoyances.
- Do people already spend time or money on a workaround? Spreadsheets, agencies, freelance labour, partial tools — a workaround is the strongest signal that the pain is real.
- Have at least five people told you, unprompted, that they have this problem? Polite agreement to a survey question does not count. Stories about their own past behaviour do.
- Would the problem still exist in 12 months? Trends, regulation, and platform changes can dissolve a real problem overnight. Check whether anything you are counting on is fragile.
Section 2 · Customer
Who is the customer — and can you reach them?
A customer you cannot reach is the same as no customer. This section turns "everyone" into a specific, reachable person.
- Can you name one channel where the customer already spends time? (Reddit, Slack groups, conferences, podcasts, a YouTube niche.) Reachability beats addressability.
- Can you describe their day in enough detail that you would recognise them in a coffee shop? ICP specificity is a forcing function for distribution choices.
- Have you talked to five of them in the last two weeks? Not surveyed — talked. A 30-minute conversation beats a 300-response survey for early-stage validation.
- Do they already pay for something that solves a part of this problem? Money flows to where the workaround lives. That is your competitive set.
- Is the buying decision made by one person, or by a committee? The validation experiment is very different for a solo buyer vs a B2B committee.
Section 3 · Solution
Does the proposed solution fit the problem?
The cheapest solution is the one that exists already — or one that piggybacks on a workaround the customer already uses. The goal of this section is to find the smallest useful answer.
- In one sentence, can you describe what the customer does differently after using your product? If the answer is vague ("they save time"), the solution is not yet concrete enough.
- What is the smallest possible version of the solution that still delivers the core outcome? Anything that does not contribute to that outcome is feature creep.
- Could the customer solve the problem with a manual workaround, a Notion template, a Loom video, or a 30-minute freelancer engagement? If yes, the MVP must beat the manual version on price, speed, or quality.
- Does the solution require the customer to change their existing habits? Every required habit change is a friction cost; budget for it.
- Is the solution obviously better than the workaround in a way the customer can describe to a friend in one sentence? Word-of-mouth depends on that sentence.
Section 4 · Market
Is the market reachable, and is it changing?
A market exists when enough reachable people experience the problem, spend money on workarounds, and could plausibly switch. Reachability matters more than total addressable size for a solo founder.
- Can you name at least three existing alternatives the customer uses today? Zero alternatives usually means the problem is not yet felt as a problem.
- Is there something shifting in the market right now — a new regulation, a new platform, a new behaviour — that makes this problem newly felt or newly addressable? Tailwinds compound.
- Are there competitors already serving this market? Some competition is good (demand is proven). A crowded market with no obvious positioning is a yellow flag.
- Is the buyer segment narrow enough that you can serve them well in a quarter? "Every small business in the world" is not a target — pick one slice.
- Have you mapped at least one realistic distribution path into the market? A market you cannot reach is the same as no market.
Section 5 · Distribution
How will you reach the first 100 customers?
Distribution is the most-skipped section of a startup plan and the most common reason plans fail. If you cannot reach the first customer, no other assumption matters.
- Have you picked one primary channel and one backup? A solo founder with five channels has zero channels.
- Can you describe the first 100 customers by name, channel, and triggering event? A reachable list beats an abstract persona.
- Is the channel repeatable? A viral post that lands once is a lottery ticket; SEO, community, or sales cadence is a system.
- What does it cost in time or money to reach one customer through this channel? If the answer is "I don't know yet", that is the first thing to find out.
- Have you actually run the channel for two weeks and measured the response? Plans about distribution are guesses; measurements are evidence.
Section 6 · Willingness to pay
Will customers pay, and how do you know?
A polite "I'd buy that" is not willingness to pay. Willingness to pay is a credit-card, a wire, a signed contract, or a pre-order — anything that converts intent into a real commitment.
- Have you named a specific price, in dollars, for a specific customer segment? "Free" or "TBD" is not a price.
- Has anyone paid, even a small deposit, before you built anything? Pre-orders, deposits, and letters of intent are the only payment signal that does not require a finished product.
- Have you asked five target customers to put a real number on what this would be worth to them? Anchoring questions ("would you pay $X?") are unreliable; open-ended questions ("what would you expect to pay?") are better.
- Does the price cover the cost of acquiring that customer plus the cost of serving them? Negative unit economics cannot be rescued by growth.
- Is the willingness recurring (subscription, retainer) or one-time? Recurring revenue changes the assumption stack and the MVP scope.
Section 7 · Product-market fit
Do users repeatedly receive value?
Product-market fit is not an announcement; it is a pattern of behaviour. Retention, organic referrals, and unprompted word-of-mouth are the signals; launch-day traffic is not.
- Do a meaningful share of users return on day 2, day 7, and day 30? Retention curves beat top-of-funnel metrics for early-stage products.
- Have at least some users sent the product to a friend or colleague, unprompted? Word-of-mouth is the strongest early signal of fit.
- When you ask "what would you miss if we shut down?", do users name a specific feature or outcome? Vague praise ("it's nice") is not fit; named losses are.
- Are users finding the product without you driving traffic? Organic discovery, search, or word-of-mouth is the test that marketing spend cannot fake.
- Can you name the one behaviour that correlates with retention? That behaviour is the thing to optimise and protect.
Section 8 · MVP
What is the smallest experiment that tests the riskiest assumption?
An MVP is not a small product. It is the smallest test of the assumption that, if false, would invalidate the rest of the plan. If the test does not produce a clear yes/no answer, it is not yet small enough.
- Have you named the single riskiest assumption the MVP must test? "People will use it" is not specific enough; "10% of trial users will convert to paid within 14 days" is.
- What is the cheapest possible version of that test? Landing page, concierge MVP, Wizard-of-Oz, single-feature scope, paper prototype — pick the smallest.
- What does a passing test look like, in numbers, with a specific threshold? "Positive feedback" is not a passing test; "40% of interviewed users commit to a deposit" is.
- How long will the test take to produce a signal? If the answer is more than four weeks, narrow the scope.
- What is the smallest set of features required to run the test, and what can wait? Everything not on the test path is feature creep.
Section 9 · Problem-solution fit
Do users actually reach for your solution when the problem hits?
Problem-solution fit sits between problem validation and product-market fit. It is the moment where the right customer consistently reaches for the right product in the right situation. The signal is repeated, unprompted use — not signups.
- Do users describe the moment they reach for the product in their own words? Their words are your marketing.
- Is there a specific triggering event that drives usage? Daily, weekly, monthly — the cadence should match the pain cadence.
- Have you watched a real user try the product on a real problem? Observation beats survey.
- Does the user describe the outcome ("I shipped the report in an hour"), or just the activity ("I used the tool")? Outcomes are the signal.
- If the product disappeared tomorrow, would the user have to build a workaround? Named workarounds are the strongest evidence of fit.
Evidence hierarchy
Not All Evidence Is Equal
The most common validation failure is treating encouragement as proof. Signals differ in how much uncertainty they remove: what someone says costs them nothing, what someone does costs them something, and what someone pays costs them the most. Rank your evidence before you decide anything.
Weaker signals
These are cheap for the other person to give. They are worth collecting early — they generate hypotheses — but they do not justify building.
- Your own conviction that the problem is real
- Compliments on the idea from friends, peers, or an audience
- Survey answers about hypothetical future behaviour
- Email signups with no further commitment asked for
- Social media likes, upvotes, and "I would use this" replies
Stronger signals
These cost the other person time, money, or reputation. They do not guarantee anything, but each one removes more uncertainty than the entire list above.
- The same customer describing the problem unprompted, more than once
- Someone already paying for a workaround, a competitor, or manual labour
- Pre-orders, deposits, or a signed letter of intent
- A paid pilot, even a small or discounted one
- Repeated product usage without you prompting it
- A second purchase, or a renewal nobody had to chase
No single signal proves an idea will work. A paid pilot can still fail to become a business, and a quiet launch can still find a market. Stronger evidence does not predict the outcome — it narrows the range of things you could still be wrong about, which is the only thing validation can honestly do for you.
Decision framework
From checklist to decision
Validation is a sequence of evidence-gathering steps, not a single test. Use the framework below to move the checklist output into a build / don't-build decision.
Problem
Run the problem checks. If the answer is no, the project is not worth pursuing — there is no plan that rescues a non-existent problem.
Customer
Run the customer checks. If you cannot name a reachable customer, the problem exists but the project does not.
Solution
Run the solution checks. If the solution does not produce a clear outcome the customer can describe, the plan needs a different shape.
Market
Run the market checks. If the market is not reachable or has no plausible distribution path, the project is unfundable.
Distribution
Run the distribution checks. If you cannot describe the first 100 customers and how to reach them, the plan is incomplete.
Payment
Run the willingness-to-pay checks. If nobody will commit real money for a real outcome, the business model is the assumption to test.
Retention
Run the product-market-fit checks on real users. If retention is flat and word-of-mouth is zero, the product is the assumption to test.
MVP experiment
Design the smallest experiment that tests the single riskiest remaining unknown. The MVP is the test, not the product.
Decision
Decide to build, narrow the scope, or kill the project. Update the checklist with what you learned and re-run the section that produced the most new evidence.
The framework is sequential, but you can re-enter earlier sections when a later section produces new evidence. Most first-time founders learn something that rewrites at least one earlier section.
When the evidence is weak
What To Do If Validation Fails
Weak evidence is not a verdict on the idea, and it is not a verdict on you. It usually means one specific assumption was wrong — and the useful move is to find which one and change only that, rather than abandoning the whole plan or pushing ahead anyway. Six things you can change, roughly cheapest first:
Revisit the problem
If nobody recognises the problem in their own words, you may have described a nuisance rather than a cost. Go back to interviews and listen for what people already spend time or money working around.
Narrow the customer segment
Lukewarm reactions across a broad audience often hide a strong reaction inside a narrow one. Pick the sub-group that reacted most and re-run the same checks on them alone.
Change the solution hypothesis
The problem can be real while your proposed fix is wrong, too big, or too disruptive to adopt. Keep the problem, replace the solution, re-test.
Test another acquisition channel
A channel result measures the channel as much as the idea. Failing to get traction on one platform tells you little about whether the demand exists elsewhere.
Test pricing
Refusal to pay a given price is not refusal to pay. Try a different model, a different unit, or a different buyer inside the same organisation before concluding there is no willingness to pay.
Run a smaller experiment
If a test was too big to produce a clean answer, shrink it. A single well-run conversation that ends in a commitment beats a launch that produces ambiguous traffic.
Treat validation as a set of dials, not a pass/fail grade. Most ideas that eventually work were changed by their early evidence rather than confirmed by it. Deciding to stop is also a legitimate outcome — the checklist exists to make that decision cheaply, before the build, rather than expensively after it.
Common mistakes
Eight validation mistakes first-time founders make
Each mistake has a named failure mode and a counter-move. The list is opinionated on purpose — these are the patterns that show up most often in real founder interviews.
Mistake 1
Building before talking to customers
Counter-move: talk to five target customers this week, before writing a line of code. The conversations produce a sharper ICP than any persona template.
Mistake 2
Confusing compliments with demand
Counter-move: ask for commitments, not opinions. A credit card, a deposit, a signed letter of intent — anything that converts polite praise into a real cost.
Mistake 3
Assuming everyone is a customer
Counter-move: pick one specific segment you can describe in a sentence. Reachability beats size. The other segments can come later.
Mistake 4
Relying only on TAM
Counter-move: name the first 100 customers and the channel that reaches them. Total addressable market is for investors, not for solo founders.
Mistake 5
Choosing pricing without evidence
Counter-move: pick a price that covers your unit economics, then ask five customers what they would actually pay. Open-ended questions beat anchored ones.
Mistake 6
Measuring vanity metrics
Counter-move: optimise for retention, organic referrals, and unprompted word-of-mouth. These are the metrics that correlate with durable growth.
Mistake 7
Building an oversized MVP
Counter-move: cut every feature that does not contribute to the single riskiest assumption. If the MVP takes more than four weeks, it is not minimal yet.
Mistake 8
Ignoring negative evidence
Counter-move: treat each "no" as the most informative response. If three customers in a row tell you the same negative thing, the plan needs to change, not the customers.
When to build
You do not need perfect certainty to build
The checklist is evidence gathering, not a permission slip. A founder does not need to answer every question with yes before writing a line of code. The goal is to reduce the most important unknowns first, then build the smallest experiment that tests the next unknown.
If you can name the riskiest assumption and the cheapest experiment that tests it, that is enough to start. If you cannot, the checklist is telling you what to do next.
Re-run the section that produced the most surprising answer after every experiment. Most first-time founders learn something that rewrites at least one earlier section. That is the point of validation — the plan changes as the evidence accumulates.
Where the tool fits
When To Use Startup MRI
This checklist is free to use and works on paper. Startup MRI is useful when you want the same structure applied to your specific idea, with the riskiest sections named for you. Reach for it in these situations:
- Evaluating a brand-new idea and wanting a structured starting point rather than a blank page
- Comparing several startup ideas and needing a consistent basis for the comparison
- Preparing customer interviews and wanting to know which assumptions to probe
- Deciding what to validate next after a round of experiments
- Reviewing an assumption in an existing startup that has quietly gone untested
The path from here
Each of these does a different job. Pick the one that matches the question you are holding right now.
- Startup Idea Evaluator
Score one idea across all nine checklist areas and see which section has the weakest evidence.
- Startup Score Calculator
See how the individual scores are calculated from your inputs, before running a full report.
- Startup Idea Validator
Work through validation for a specific idea type — SaaS, marketplace, mobile app, and others.
- Example Startup MRI Reports
Read a finished report before submitting anything, so you know what you would get back.
- Get a 7-Day Validation Action Plan
Submit your idea and get a deterministic 7-day plan derived from the highest-risk assumption — actions, evidence, and a Day-7 decision rule.
Startup MRI does not predict whether a startup will succeed, and no tool honestly can. It applies the same checks on this page to your inputs and tells you where your evidence is thinnest.
FAQ
Frequently asked questions about startup validation
Short answers, in the same vocabulary the Startup Validation hub uses. Longer answers live in the linked articles.
- What is a startup validation checklist?
- A startup validation checklist is a structured list of yes/no evidence checks across nine areas — problem, customer, solution, market, distribution, willingness to pay, product-market fit, MVP, and problem-solution fit. Each check is something a solo founder can answer in a week. The output is a list of which assumptions have evidence and which still need a test.
- How do I validate a startup idea?
- Run the checklist in order: problem → customer → solution → market → distribution → willingness to pay → product-market fit → MVP. Stop at the first section where the answer is no and run the cheapest experiment that tests that section. A free Startup MRI analysis scores the same nine areas and points you at the section most worth testing first.
- What should I validate before building an MVP?
- Before an MVP, validate problem, customer, solution, and market. If the problem is real, the customer is reachable, the solution fits the problem, and the market is not closed to you, an MVP is justified. Distribution and willingness to pay are tested inside the MVP.
- How do I know if a startup problem is real?
- Five unprompted stories from five different people that they have this problem — not polite agreement to a survey. The strongest signal is a workaround: the more time or money they spend working around the problem today, the more real it is.
- How do I validate willingness to pay?
- Ask for a real commitment, not an opinion. A credit card, a deposit, a signed letter of intent, or a pre-order — anything that converts intent into a cost. Run a 30-day concierge at the business-model price with five paying customers; that is the cheapest test of recurring willingness to pay.
- How do I validate product-market fit?
- Look for retention curves that flatten above zero, organic referrals that arrive without prompting, and named losses ("I would miss X if you shut down"). A launch-day spike is not fit; a flat retention curve is. Run the product with at least 20–50 real users for 4–8 weeks before judging.
- How long does startup validation take?
- Plan for two to six weeks of structured work: one to two weeks on problem interviews, one to two weeks on a landing-page or smoke test, and one to two weeks on a willingness-to-pay test. A free Startup MRI analysis takes 60 seconds and points you at the section most worth testing first.
- Can AI validate a startup idea?
- AI can score the structured inputs you give it and surface the assumptions worth testing first. It cannot talk to your customers, run experiments, or commit real money. Use AI to identify the riskiest unknown; use customer conversations to test it.
- What evidence should I collect before building?
- Before building, collect: five problem stories from five different people, one reachable channel where the customer already spends time, one specific price the customer has agreed to, and one named workaround the customer uses today. Anything less is guesswork.
- What should I do if validation results are negative?
- Treat each negative answer as the most informative response. Update the plan, narrow the customer segment, change the price, or pivot the solution. Do not collect more negative evidence and then ignore it; re-run the section that produced the most surprising answer.
Use the checklist, then run the analysis
The checklist tells you which sections need evidence. Startup MRI tells you which section to test first. The next step is the cheapest experiment you can run this week.