Startup Idea Validation: The Checklist Before You Build Anything

The most expensive mistake in startups is building something nobody wants. Validation exists to reduce that risk — but most founders either skip it entirely or do it wrong (asking friends if the idea sounds cool doesn't count).

Here's a structured checklist for pre-build validation.

Step 1: Write the problem statement first, not the solution

Before you validate anything, write this sentence: "[Specific person] struggles with [specific problem] when [specific situation] because [specific root cause]."

If you can't fill in all four blanks specifically, you don't have a problem statement. You have a vague idea. Keep working until you can fill it in.

Step 2: Find 20 people who have this problem right now

Not who might have it. Not who could have it. People who actively experience this problem and can describe it in their own words.

These don't have to be strangers. But they can't be your friends, your family, or people who will tell you what you want to hear. LinkedIn is your best tool here — find the exact job title and company size your solution targets, and send direct messages.

Step 3: Run 10 problem discovery interviews

A problem interview has one goal: confirm that the problem is real, frequent, and costly.

The questions are not about your solution. They're about the problem.

• "Walk me through the last time this happened. What did you do?"
• "What have you tried so far to solve this? Why didn't those work?"
• "How much time/money does this cost you roughly?"

If 8 of 10 people describe the exact same pain without any prompting, you have a problem worth pursuing.

Step 4: Understand what they already use to solve it

Every problem has a current solution — even if it's "I just live with it" or "my team does it manually in Excel." Understanding the incumbent solution tells you what you're competing against, what switching costs look like, and what your wedge has to be.

Step 5: Test willingness to pay with a number

In at least 3 interviews, say: "If this problem were solved completely, would you pay ₹X per month for it?" Use a number that would make the business viable, not a number they're comfortable with.

Watch the reaction. "Maybe" is not a yes. "I'd need to check with my boss" from an individual founder is a yes. "We already spend ₹5,000 on something worse" is a very strong signal.

Step 6: Size the addressable market — but be honest

Top-down market sizing ("the Indian SaaS market is $10 billion") tells an investor nothing about whether you can build a real business. Bottom-up works: [number of customers] × [price per customer per year] = addressable revenue.

If the number isn't at least ₹50 crore at scale, it's a small market. That's not disqualifying, but it limits what kind of business you can build.

Step 7: Search for existing solutions obsessively

Spend 4 hours searching: Product Hunt, Capterra, LinkedIn company search, Crunchbase, IndianWeb2 for India-specific products. If the solution already exists, that's not automatically bad — it validates the problem. But it changes your question from "does this market exist?" to "why will customers switch to us?"

Step 8: Define your unfair advantage

Can you articulate why you are the right team to build this, in a way that a reasonable person would find convincing? This could be: domain expertise, proprietary data access, a distribution advantage, a network, or a technology insight.

If the honest answer is "we're just going to work really hard," that's not an unfair advantage. That's table stakes.

Step 9: Build the smallest possible test

Before writing code, ask: what's the simplest thing I can build to test the core assumption? This might be: a landing page with a waitlist form. A manual process done by humans. A WhatsApp group. A spreadsheet shared with 10 test users.

If nobody engages with the lowest-friction version, the full product won't change that.

Step 10: Define your success criteria in advance

Before you run the test, write down: "I will proceed if X. I will stop if Y." Without this, confirmation bias will make you see success in any result.

If 8/10 people say the problem is real but only 1/10 would pay for the solution, what does that tell you? Define that interpretation before you start, not after.

Validation doesn't guarantee success. But building without it almost guarantees you'll build the wrong thing.