Startup validation checklist

The average failed solo build wastes 14 weeks. Most of that time was spent on something that could have been validated in four minutes. Here is what you need to know before you open a code editor.

How to use this checklist

Work through each item before you commit to building. Items 1–3 are the minimum — if you cannot pass pain evidence, volume, and specificity, stop and find the evidence before you go further. The remaining five items reduce risk and sharpen your plan, but some can be discovered post-launch. None of them can substitute for items 1–3.

For each item, the question is not “do I think this is true?” but “can I point to specific evidence that this is true?” If the answer is no, you have not checked the item.

The 8 items

01
Pain evidenceReal people describe this problem in their own words, not surveys, not hypotheticals. You can point to specific posts.
Passing this item means you can point to at least 8–10 specific posts where real people describe the frustration in concrete terms. The posts should be unprompted — not responses to your survey or replies to your question in a community. If the only evidence you have came from conversations where you introduced the idea first, you have not passed this item. Evidence written before you showed up is the only kind that counts.
Proven covers this: Pain Evidence section: 8–15 sourced quotes, each linked to the original post.
02
VolumeThe pain appears in multiple communities and contexts, not just one niche subreddit with 200 members.
Volume matters because a single community can be a vocal minority that doesn't represent the broader market. If the same pain appears in Reddit, Hacker News, and App Store reviews of existing products, it signals a cross-sectional problem rather than a niche complaint. One community with 10 passionate posts is interesting. Three communities with 40 posts combined is a market signal.
Proven covers this: Pain Score and signal count, showing how many posts were found across how many sources.
03
SpecificityPeople describe the pain in concrete terms: what triggered it, what it cost them, what they tried. Vague complaints don't convert into buyers.
Look for posts where someone describes a specific event (a client they lost, a deadline they missed, a process that broke) because of this problem. Vague complaints like 'X is annoying' reflect mild inconvenience, not urgent need. The more specific the language in the posts, the more accurately you can predict willingness to pay. Specificity is the single strongest predictor of commercial viability in the pain evidence.
Proven covers this: Each pain quote is scored for specificity before it surfaces in the brief.
04
Competitor mapYou know what existing solutions people have tried and why they switched, gave up, or complained about them publicly.
A competitor map is not a feature comparison matrix. It is an evidence-based picture of what people tried, what they liked, and where existing products failed them. App Store reviews of competitors are the single best source for this: filtered frustration, specific feature requests, and switching reasons in one place. If competitors exist and have strong reviews with no obvious gaps, that is a signal too.
Proven covers this: Competitor Map section: companies found in the wild with positioning gaps identified.
05
Willingness to payAt least some posts mention money — what people paid, what felt too expensive, what they would pay if something better existed.
This is the most commonly skipped item on this list and the most predictive of commercial failure. Pain evidence tells you the problem exists. Willingness-to-pay evidence tells you whether it is worth solving commercially. Look for explicit price mentions, behavioral signals (people paying for an inferior solution because nothing better exists) and comparative cost signals, where someone describes how much the current workaround costs them in time or money.
Proven covers this: Monetization section: pricing signals aggregated from posts that mention price.
06
Target personaYou can describe the person with this pain in one paragraph — their role, what triggers the problem, how often, and what they've already tried.
The persona should come from the evidence, not from your assumptions about who would find your product useful. If the posts are written by freelance designers but you assumed your customer was a marketing manager at an agency, that gap matters for your messaging, your pricing, and where you find your first customers. A persona built from evidence is specific and testable — you can check it against the people you talk to.
Proven covers this: Target Persona section — built from demographic signals in the evidence posts.
07
Go-to-market pathYou know where your buyers already hang out and what angle would make them click. Not a launch plan — a day-one distribution path.
The communities where you found the pain evidence are your day-one GTM. If 30 of your best signal posts came from r/freelancers, that community is your first channel — not as a target to spam, but as a place where your product would be genuinely useful to people already expressing the need. GTM path at this stage means day-one channel, not product launch strategy.
Proven covers this: Go-to-Market section — communities and platforms extracted from the evidence sources.
08
Risk mapYou've identified the two or three things most likely to kill this idea and have a plan to test them early.
The risk map should be specific to your evidence, not a generic startup risk checklist. If the competitor map shows one dominant player with strong reviews and no obvious gaps, that is a risk. If willingness-to-pay signals are thin, that is a risk. If the persona is real but the problem only occurs quarterly, that is a risk. Naming the risks before you build is what lets you design early tests around them instead of discovering them six months in.
Proven covers this: Risk Map section — patterns most likely to kill this specific idea, from the evidence.

Founder's Brief dashboard showing all 10 sections in the sidebar, Pain Score, and Build it verdict — A Founder's Brief covers all 8 checklist categories in one report — Pain Score, evidence, competitors, persona, GTM, risks, and verdict.

What does not count as validation

Several things feel like validation but aren't. Friends and family feedback does not count — they want you to succeed and their signal is biased by that. Landing page waitlist signups without payment or friction do not count — most people will sign up for a free thing they are mildly curious about. Survey responses do not count because questions prime the answer: “would you pay for X?” is not a market signal, it is a hypothetical.

Twitter polls, communities built around supporting indie builders, and “customer interviews” with people in your own audience all have the same flaw: selection bias. The people you can reach are not the same as the market you are entering.

What does count: pre-existing Reddit and HN posts written before you had the idea, App Store reviews of competitors describing what is missing, someone paying money for an inferior solution because nothing better exists, and threads where the top reply to “is there a tool for X” is “no, and I need one badly.”

Red Flags section showing evidence-based risks and challenges to the idea — Red Flags — evidence that challenges the idea, pulled from the same posts as the pain evidence.

How Proven covers this checklist

A Founder's Brief from Proven covers all eight items in about 4 minutes. The Pain Score covers items 1–3. The Competitor Map covers item 4. The Monetization section covers item 5. Target Persona, Go-to-Market, and Risk Map are dedicated sections covering items 6–8. The brief does not replace your judgment on what to build — it gives you the evidence to make that judgment from something real.

For a deeper walkthrough of the validation process, read the full guide on how to validate a SaaS idea.

Frequently asked questions

Do I need to check all 8 items before building?

Items 1–3 — pain evidence, volume, and specificity — are the minimum. Without those, nothing else matters. The rest add confidence and reduce risk, but you can discover some of them post-launch. If you're missing your go-to-market path, you can find it by talking to early users. If you're missing pain evidence entirely, stop and find it before you write a line of code.

What if I can only find evidence for 4 of the 8 items?

Build on the ones you have and use the missing items as your first research priorities after launch. The checklist tells you which items to de-risk first, not whether to build at all. Missing a go-to-market path is a different risk than missing pain evidence — the first is a distribution problem, the second is an existence problem.

Can Proven help me check all 8 items?

Yes — a Founder's Brief covers all eight. Pain evidence, volume, and specificity come from the Pain Evidence section and Pain Score. Competitor map is its own section. Willingness to pay appears in the Monetization section. Target persona, go-to-market path, and risk map are dedicated sections. The brief gives you evidence for all eight in about 4 minutes.

Should I validate before talking to customers?

Do the market evidence research first. Talking to customers too early means you are testing your description of the problem, not their actual experience of it. Get the market evidence first — Reddit posts, HN threads, App Store reviews — then go talk to people who fit the persona the evidence identified. Your conversations will be sharper and your questions will be better.

What is the most commonly skipped item on this checklist?

Willingness to pay. Founders find pain evidence, build a competitor map, and start building — skipping the question of whether their target persona will actually pay to solve the problem. Pain evidence tells you the problem exists. Willingness-to-pay evidence tells you whether it exists at a scale and urgency that supports a commercial product.

Written by Dairon Canel with AI assistance for research and structure.

Try Proven free ← Back to Proven