How to Validate a Startup Idea Before Writing a Single Line of Code

Validation is the most discussed and most consistently misunderstood phase of building a startup. Founders know they are supposed to validate before building. Very few know specifically what they are supposed to validate or how to know when they have done enough of it.

The confusion is understandable. Most validation advice describes what to do but not why, which means founders do the motions without achieving the actual goal. They run customer discovery calls, build a landing page with an email capture, maybe get fifty people to sign up, and call that validation. Then they spend six months building a product nobody pays for.

The Four Types of Validation

Validation is not a single activity. It is four separate questions that require different methods, and failing any one of them produces a different kind of startup failure.

Problem validation. Does the problem you are solving actually exist at a painful enough level that people are actively trying to do something about it? This is different from "is there a problem?" Almost any observable friction is technically a problem. The relevant test is whether people feel the problem acutely enough to have already looked for a solution, already built a workaround, or already paid something (in time, money, or effort) to reduce it.

A problem that has no active attempts at solution is usually not painful enough to build a business around. The clearest signal of real problem severity: people are currently doing something messy, expensive, or time-consuming because no good solution exists yet.

Solution validation. Does your proposed solution actually address the problem better than what people are currently doing? This is where most founders stop too early. Getting five people to say "that sounds useful" is not solution validation. Solution validation requires showing people something close enough to a real solution that they can evaluate whether it actually solves their problem. That means a prototype, a wizard-of-oz demo, or a manual process done on their behalf.

Willingness-to-pay validation. Will people pay for the solution at a price point that makes the business viable? This is the test most founders delay the longest because it introduces the most rejection risk. It is also the test that matters most. An enthusiastic user who will not pay is market research, not a customer.

The only reliable way to validate willingness to pay is to ask for money. Not "would you pay?" That question produces socially polite answers. The test is offering to take payment. A letter of intent, a deposit, a pre-order. Friction produces honesty.

Distribution validation. Can you reach the people who have this problem in a way that is sustainable and repeatable? The best product in the world fails if you cannot find and reach the customers who need it. Distribution validation means identifying at least one channel where your ICP is concentrated and reachable, and confirming that they respond to your message.

The Sequence That Works

These four validations are not sequential in a strict sense, but problem validation must come before solution validation, and willingness-to-pay validation should come before significant building.

The most common failure mode: founders start with a solution they like, run a few conversations to confirm the problem exists at a surface level, and move immediately to building. They skip the hard tests because the early conversations felt validating. Six months later, the product exists but nobody is willing to pay what it would cost to make the business work.

In my experience, the teams that validate well treat every early conversation as an attempt to prove themselves wrong, not right. They are looking for the specific condition that would make the idea not worth pursuing. If they cannot find that condition after thirty or forty conversations, the idea has earned the right to be built.

The Minimum Viable Test for Each Stage

Problem: talk to twenty people who have the problem. Ask them what they are currently doing about it. If more than half have tried something specific, the problem is real enough to continue.

Solution: show something to ten people who have the problem. Watch what they do, not what they say. If seven of ten can use the solution to make progress on their actual problem without significant prompting from you, the solution direction is worth developing.

Willingness to pay: ask five people to commit money before the product is finished. If zero of five will commit anything, the value proposition is not landing. If three of five will commit at a price that makes the business viable, you have enough signal to build.

Distribution: reach your first ten customers through a specific channel. If you cannot name the channel, you do not have distribution validation.

The first ten customers guide covers the mechanics of finding and converting early customers once you have passed the validation gate. The PMF signals piece covers what you are looking for after the product is in market. Y Combinator's library on validation has the most practically useful writing on this phase from founders who have gone through it.