How to Validate a Startup Idea Before Writing Any Code

The CB Insights post-mortem on failed startups has one finding that should change how every founder thinks: 42% of startups fail because there's no market need. Not because of bad execution, bad timing, or bad luck — because they built something nobody wanted.

This isn't a technology problem. Most of those founders were technically capable. The failure happened before they wrote a line of code.

Here's how to avoid it.

---

Why Most Validation Fails

Founders validate ideas badly for one consistent reason: they ask the wrong people the wrong questions.

The wrong people: your friends, your family, your co-founder, and your potential investors at the idea stage. All of them have incentives to be encouraging. None of them will tell you your idea is bad.

The wrong questions: "Would you use this?" and "Do you think this is a good idea?" Both are hypothetical. Hypotheticals are worthless. People systematically overestimate what they would do in a future scenario, especially when they know you've invested emotionally in the answer.

The right question is a variant of: "Tell me about the last time you experienced this problem."

That question surfaces real experience, not imagined future behavior. The answer — or the absence of one — tells you everything.

---

The YC Customer Development Framework

The framework YC teaches for customer development comes largely from Steve Blank's work and Rob Fitzpatrick's The Mom Test, a book worth reading before you talk to a single user.

Fitzpatrick's core insight: "You shouldn't ask anyone whether your business is a good idea." Instead, ask about their life, their problems, and their current solutions.

The three questions that actually work:

1. "Tell me about the last time you experienced [problem]." — Real or not? How frequent?
2. "How have you tried to solve this?" — Are they solving it at all? With what? How much are they paying?
3. "What's the worst part about how you handle it today?" — This is the gap your product fills.

If someone has never experienced the problem, can't remember the last time, or is solving it adequately with a spreadsheet — your idea may be solving a problem that isn't painful enough to pay for.

If someone pulls out a credit card and asks if they can pay you before the product exists — that's a different conversation entirely.

---

Who to Talk To

The targeting problem: you need to talk to the people who have the problem, not the people who might theoretically have it.

Finding the right people:

• Reddit is underrated for this. Every niche has a subreddit. Post about the problem (not your solution). Read what people complain about. DM the people who describe the pain most specifically.
• LinkedIn for B2B problems. The job title filter is powerful. Send a note that says you're researching a problem, not selling anything, and ask for 15 minutes.
• Communities you're already in. The founder with an unfair advantage is the one solving their own problem — they already know where the other sufferers are.
• YC's advice is direct: "Do a YC-style interview with yourself." Would you fund a company solving this problem for this customer? If not, why not?

Talk to at least ten people before drawing conclusions. Twenty is better. The signal you're looking for: consistent, unprompted mentions of the same pain, from people who are already spending money (time or cash) on inadequate solutions.

---

The Smoke Test

Once you've validated that the problem is real and that people are suffering from it, you still need to test whether they'll change their behavior.

A smoke test is the smallest possible signal of intent. The classic example is Dropbox: Drew Houston created a demo video showing how Dropbox would work — before Dropbox existed — and put a signup form at the end. Overnight, 75,000 people signed up. That's demand validation without shipping a product.

Four smoke test formats that work:

Landing page with a waitlist. Describe the product, include pricing, ask for an email. A 10%+ conversion rate from organic traffic is a good signal. Less than 3% suggests the messaging, the offer, or the problem isn't compelling enough.

Pre-orders. Charge before you build. Gumroad makes this easy. If you can't get ten people to pay even a small amount, you don't have product-market fit. If you can, you have validation and cash.

Concierge MVP. Do manually what your software will eventually automate. Instacart's earliest version was their co-founders going to grocery stores themselves. Users thought they were using an app. This tests whether people will use the service, not whether they like the idea of it.

"Wizard of Oz" MVP. The interface looks like software. Behind the scenes, a human is doing the work. Tests user behavior without the engineering investment.

Tools worth knowing:

• Carrd — one-page landing sites in 20 minutes
• Gumroad — pre-orders without engineering
• Loops — waitlist email management

---

How to Read the Results

Most founders find ways to see validation in weak signals. Here's a more honest read:

Strong signals:

• People describe the problem without being prompted
• They're already paying for inadequate solutions
• They ask when your product will be available before you've said anything about it
• They offer to prepay

Weak signals (that feel strong):

• "That sounds like a great idea" from people who like you
• 50 waitlist signups from friends and colleagues
• One very enthusiastic potential user
• High email open rates on a cold outreach campaign

Signals to take seriously as negatives:

• "I'd probably just use [existing tool] for that"
• "I could see some people wanting that"
• Silence when you ask if they'd pay for it
• They can't remember the last time they had the problem

The bar is high for a reason. Building software takes months of your life. Shipping something nobody wants takes the same time as shipping something people need. The validation work is what separates the two outcomes.

---

When to Stop Validating and Start Building

The question founders ask too rarely: "Am I still learning something, or am I just delaying?"

You're ready to build when:

• You've talked to 15–20 people with the problem
• At least 3 of them have offered to pay or prepaid
• You have a specific, describable customer in mind (not "anyone who...")
• You know where to find your first 50 customers

You're not ready when:

• You haven't talked to anyone outside your network
• You haven't asked anyone about money
• You're still unclear on who specifically has this problem

Build too early and you waste months on the wrong thing. Validate too long and you use it as a way to avoid the real risk of shipping.

The productive version of validation ends with a decision. Either you've found enough signal to build — in which case, build the smallest possible version and get it to those same people within two weeks — or you've found enough evidence to change direction.

---

From Validation to Build

Once you have the signal, the next question is execution. Most founders can either build the MVP themselves or need to hire someone.

If you're hiring: the best outcomes we've seen come from founders who've done their validation work before they engage a builder. They have a specific problem, specific customers, and a specific scope. That clarity is what lets a builder ship something useful in 24–48 hours instead of spending weeks asking scope questions.

Post a bounty on OneDayMVP with your validated problem, your target customer, and three features that address the core pain. You'll find builders who've shipped dozens of MVPs in this exact space.

---

Sources and further reading:

• Rob Fitzpatrick: The Mom Test — the best book on customer interviews
• Steve Blank: The Four Steps to the Epiphany — the origin of customer development
• Michael Seibel (YC): How to Talk to Users
• YC Library: Customer Discovery
• Starter Story: What these founders wish they'd validated first