How to Validate a Startup Idea Before Building Anything

The spreadsheet showed everything: market size, competitor analysis, feature comparisons, revenue projections. Six months of research, neatly organized into tabs and charts.

What it didn't show: a single conversation with a potential customer.

"I didn't want to bias my research with anecdotes," she explained later. "I wanted data."

The data said the market was huge. The data said competitors were weak. The data said there was room for disruption.

The customers said they didn't have the problem she was solving.

Six months of building. Fifty thousand euros of runway. A product that worked exactly as designed—for a problem that existed mainly in spreadsheets.

Validation isn't about proving your idea is good. It's about discovering whether anyone needs what you're planning to build.

Why Most Idea Validation Fails

The word "validation" has been corrupted.

For many founders, validation means confirming what they already believe. They seek evidence that supports their idea and dismiss evidence that contradicts it. They ask leading questions. They interpret polite interest as genuine demand.

This isn't validation. It's confirmation bias with extra steps.

Real validation is uncomfortable. It means genuinely not knowing whether your idea will work—and being willing to discover that it won't.

The Validation Hierarchy

Not all validation signals are equal. There's a rough hierarchy from weakest to strongest:

Opinions are nearly worthless. "That sounds interesting" means nothing. People are polite. They tell you what you want to hear, especially when there's no cost to them. Stated intentions are slightly better. "I would probably use that" at least indicates some interest. But the gap between saying and doing is enormous. Behavioral signals start to matter. Someone signing up for a waitlist. Joining a beta list. Following your progress. These require small actions, not just words. Commitments are strong signals. A letter of intent. A pre-order. A deposit. Anything that involves risk or sacrifice. Money is the strongest validation. Someone paying for your solution—even a rough version, even at a discount—proves they have a problem worth solving.

The polite validation trap catches founders who mistake the bottom of this hierarchy for the top.

Validation Before Code

You don't need a product to validate an idea. You need conversations.

Start with the problem, not the solution. Don't pitch your idea. Ask about their world. How do they currently handle this challenge? What have they tried? What worked and what didn't? How much does this problem cost them—in time, money, or frustration?

The Mom Test framework helps here: ask questions that even your mother couldn't lie about. Not "Would you use this?" but "When was the last time you faced this problem? What did you do?"

Talk to the right people. Your ideal customer profile matters. Validating with the wrong segment proves nothing about the right segment. A problem that's critical for 50-person startups might be irrelevant for enterprises—or vice versa. Count the patterns. One person's enthusiasm means nothing. Two people with the same pain point is interesting. Ten people describing the same problem in similar language—now you might have something.

The Fake Door Test

Before building, you can test demand with almost no code.

A landing page describing your solution. A signup form. Maybe a price. Watch what happens.

Do people find it? Do they read it? Do they sign up? Do they pay—or at least try to?

This isn't a product. It's a probe into the market. The conversion rate from visitor to signup tells you something. The quality of signups (are they your ICP?) tells you more. Their response when you email them tells you the most.

Some founders feel this is dishonest—promising something that doesn't exist. But there's nothing dishonest about saying "we're building this, join the waitlist." You're not selling vaporware. You're measuring interest before investing months of your life.

The Concierge Approach

Sometimes you can validate by doing manually what you'll eventually automate.

If you're building a service that matches freelancers with projects, start by doing the matching yourself. Email. Phone calls. Spreadsheets. It doesn't scale—that's the point. You're not trying to scale. You're trying to learn.

This approach reveals things that market research can't: the actual workflow, the edge cases, the moments where customers get frustrated, the features they assume exist, the features they don't actually need.

You might discover the problem is different than you imagined. You might discover the solution needs to work differently. You might discover that customers will pay—or that they won't.

All of this before writing a line of code.

What Validation Actually Answers

Good validation answers specific questions:

Does the problem exist? Not theoretically—actually, in the lives of real people who would pay to solve it. Is it painful enough? People have many problems. They only pay to solve the ones that hurt. A "nice to have" solution struggles to find product-market fit. Can you reach these people? A real problem in an unreachable market is still a bad business. How will you find customers? What channels work? What does acquisition cost? Will they pay? And how much? And who controls the budget? The difference between "this would be useful" and "let me get my credit card" is the difference between a hobby and a business. Is the timing right? Some problems aren't ready to be solved. The technology isn't there. The market hasn't matured. The regulatory environment is hostile. Validation includes understanding whether now is the moment.

Red Flags in Validation

Some signals suggest your validation isn't working:

Everyone loves it. Universal enthusiasm usually means you're asking leading questions or talking to the wrong people. Real problems have skeptics. No one can articulate the problem. If potential customers can't describe the pain you're solving, they might not have it. The problem exists but alternatives are "fine." Customers need to be dissatisfied with current solutions. "It's not perfect but it works" is a warning sign. Interest but no commitment. Lots of "keep me posted" and no letters of intent, pre-orders, or design partner agreements. You're convincing more than discovering. If conversations feel like sales pitches, you've stopped validating and started selling—before you know if there's anything worth selling.

When to Stop Validating and Start Building

Validation isn't infinite. At some point, you have enough signal to move forward—or enough signal to move on.

Signs you might be ready to build:

You've talked to 20+ potential customers in your ICP. You've heard the same problem described multiple ways. You have letters of intent or pre-orders. You understand not just what to build but why it matters to the people who'll use it.

Signs you might need to pivot or abandon:

After 30 conversations, you can't find consistent pain. People are interested but not interested enough to commit anything. The problem exists but the market is tiny or unreachable.

The goal isn't certainty—that doesn't exist. The goal is enough evidence to make an informed bet.

Moving Forward

The founders who find product-market fit often describe a validation period that felt inefficient at the time. All those conversations. All those dead ends. All those hypotheses that turned out to be wrong.

But that inefficiency was actually efficiency. Each failed hypothesis was a product that didn't get built. Each honest "no" was months of development that didn't get wasted.

Validation isn't about proving you're right. It's about discovering what's true.

The spreadsheet might say the market is huge. The customers will tell you whether it actually exists.

Related Reading

• Customer Discovery Interviews: The Complete Guide
• The Polite Validation Trap
• Ideal Customer Profile (ICP): The Foundation of PMF
• Signs of Product-Market Fit

Not sure if your idea is validated? Take our free PMF assessment to discover what signals you still need before building.