The startup idea validation checklist (before you write a line of code)

Most validation advice tells you what to do.

This checklist tells you what your idea must be able to answer before you start. Work through it in order. Don't skip items. Don't rationalize past a "no."

A "no" doesn't mean the idea is dead — it means you have more work to do before you build.

Section 1: The problem

□ Can you describe the problem in one sentence without using the word "solution"?

If you can't describe the problem without describing your solution, you don't understand the problem yet. You understand what you want to build.

Example of failing this: "The problem is that there's no good tool for X." That's a product gap, not a problem. The problem is what happens to people because of that gap.

□ Have at least 5 strangers (not friends, not colleagues) described this problem to you in their own words?

Friends are polite. Strangers are honest. Five strangers independently describing the same pain in similar terms is the minimum evidence that the problem is real for more than one person.

□ Is the problem happening to people right now, not hypothetically?

"Founders will eventually need this as they scale" is not a real problem. "Founders who hit 50 employees are currently dealing with this every week" is.

□ Is the problem painful enough that people have already tried to solve it themselves?

Workarounds are the strongest signal in idea validation. If people built spreadsheets, Zapier workflows, or manual processes to handle something — they have the problem badly enough to invest their own time. See how to find your target customer's biggest complaints online for where to look.

Section 2: The market

□ Are there online communities where people with this problem gather?

Reddit subreddits, Slack communities, LinkedIn groups, Discord servers, forums. If there's no community around the problem, the market may be too fragmented or the pain too mild.

□ Have you found at least 10 posts or threads where real people describe this pain publicly?

Public complaints are your strongest market evidence. They're unprompted, specific, and searchable. How to use Reddit for market research explains exactly how to find and interpret these signals.

□ Do competitors exist — and do they have negative reviews on G2, Reddit, or the App Store?

A market with no competitors is more dangerous than one with strong ones. No competitors usually means no market. Competitors with specific, recurring complaints = opportunity.

□ Is the search volume for the problem growing, flat, or declining?

Flat is survivable. Declining is a red flag. Growing changes everything. Use Google Trends for a directional signal before spending on keyword tools.

Section 3: The customer

□ Can you describe your first customer as a real person — not a persona?

Not "B2B SaaS founders aged 28-45." A real description: "a solo founder who has hit product-market fit with one product and is now overwhelmed by the operational load of a second."

The more specific you are, the easier acquisition becomes.

□ Do you know where to find 50 of these people right now?

LinkedIn search. A specific subreddit. A Slack community. A conference. A job board.

If you can't name a specific channel where your first customer exists, you don't know who they are.

□ Have you had a conversation with at least one potential customer that you did NOT pitch?

A validation conversation has one rule: you ask questions, they talk. You learn about their problem, their current tools, their workflow, their budget. The moment you pitch, you're no longer learning — you're selling.

Section 4: The willingness to pay

□ Are people currently spending money (time or cash) on imperfect solutions to this problem?

The best customers are those already paying for something that doesn't fully solve their problem. They've proven willingness to pay. They've proven the problem is urgent enough to act on.

□ Have you asked a potential customer what they'd pay — and did the number surprise you?

Most founders anchor their pricing on their own assumptions. Ask: "If this existed today, what would you expect to pay for it per month?" Their answer reveals whether you're in the right order of magnitude.

□ Has at least one person said something equivalent to "let me know when this is ready, I need it"?

Not "that's interesting." Not "sounds useful." Not "I might use that." The phrase you're listening for is urgency — a signal that waiting is costing them something.

Section 5: The competitive reality

□ Do you understand why people stay with the existing solution even though they hate it?

This is the most important competitive intelligence question. The answer tells you what you must include in your product just to be considered — and how to analyze competitors before building walks through exactly how to find it.

□ Can you state your differentiation in one sentence that your target customer would care about?

Not "we're faster and easier to use." Every product claims that. Something specific: "We're the only tool that does X for Y, which means they get Z."

Scoring

13-15 checkboxes: build it. You have enough signal to justify a serious investment of time and money. Start with the smallest version that answers the next unknown.

9-12 checkboxes: keep validating. Real signal exists but there are critical gaps. Identify the unchecked boxes and do the work to answer them before writing code.

Under 9 checkboxes: stop. You're building on assumptions. Go back to talking to potential customers. Every assumption you're carrying is a risk you haven't earned the right to take.

The founders who build the right things don't have better intuitions. They just use checklists like this before they trust their intuitions.

Run your idea against live market signals →