Validating Demand Before You Build: What Each Signal Actually Tells You

Demand validation is the most important thing you can do before writing significant code, and it is also the most commonly rationalized away. Founders want to build, so they convince themselves that the people who expressed interest represent real demand. Often they do not.

A smoke test — a landing page with a sign-up form or a waitlist — tells you that some number of people found your description interesting enough to give you an email address. That is a meaningful signal for measuring message-market resonance, but it is a weak signal for actual willingness to pay. Email addresses are low-commitment. People sign up for things they will never use.

Presales are a materially stronger signal. Someone handing over money before a product exists is demonstrating a kind of conviction that a form submission does not. Even a token amount — $29 for early access, $99 for founding-member pricing — filters out the curious from the genuinely interested. A hundred people paying you money before you have built anything is a more reliable market signal than a thousand email signups.

Customer interviews are the most information-dense validation method, and the most frequently done badly. The goal is to understand the problem as the potential customer experiences it, not to pitch your solution and gauge their reaction. Asking "would you use this?" generates socially desirable answers. Asking "tell me about the last time you dealt with this problem and what you did about it" generates real data.

The most common false positive in demand validation is confusing enthusiasm for a problem with willingness to pay for a solution. People will enthusiastically confirm that a problem is real and serious while simultaneously having no budget for it, already tolerating their current workaround, or expecting the solution to be free.

The time to first revenue signal in our rubric is partly a proxy for how hard demand validation actually is. Opportunities that can earn the first paying customer quickly tend to be solving problems that are recognized and budgeted for. The harder it is to get paid, the more important pre-build validation becomes.