How to Validate Demand Before Coding (Without Building the Wrong Thing)

Quick answer

Validating demand before coding means producing evidence that a named customer will pay — or behave as if they will pay — for a solution to a problem they actually have, without yet having built the solution. The five pre-code evidence checks are: (1) problem interviews that surface the customer's current workaround, (2) a smoke-test landing page that measures the signup or waitlist action, (3) a manual concierge or Wizard-of-Oz pilot where the founder delivers the outcome by hand, (4) a pre-order or LOI (letter of intent) that asks for money or a written commitment, and (5) a competitive wedge test that proves the founder can reach the named customer at a cost the model supports. The build-now-vs-validate-more rule is a seven-question gate: if any answer is "I don't know," the next step is validation, not code.

The full startup-validation discipline is in How to Validate a Startup Idea Before Building. The framework below is the slice of that discipline that runs before any engineering starts — the part most often skipped by founders who have already picked a stack.

Key takeaways

• Pre-code validation is a sequence, not a single test. Problem interviews come before landing pages, landing pages come before concierge pilots, concierge pilots come before pre-orders. Skipping a rung produces evidence that cannot fail, which is not evidence at all.
• Behavior is the only honest signal. Rob Fitzpatrick's The Mom Test (2013) makes the polite-yes problem canonical. A friend saying "I would definitely use that" is not validation; a stranger handing over a credit card is.
• The cheapest credible test is rarely a survey. Surveys measure opinion. The customer can't accurately predict what they will do next month. The cheapest credible pre-code tests are artifacts the customer uses — a landing page they would sign up for, a manual service they would pay for, a pre-order form they would submit.
• A pre-order or LOI is the cleanest pre-code test. The customer pays or signs a written commitment before the product exists. Everything weaker (a survey, a "would you buy" question, a like on a tweet) is a softer proxy.
• The seven-question build-now-vs-validate-more rule gates every engineering decision. If any of the seven questions has no defensible answer, the next step is a validation experiment, not code.
• Validation is not a verdict. A clean pre-code test produces a smaller to-do list, not a green light. The product can still fail after the tests pass; the test only narrows the range of things the founder could be wrong about.

What "validate demand before coding" actually means

"Demand" is not "people would be interested." Demand is behavior under mild friction. The minimum behavior that counts as demand is the named customer performing a specific action that costs them something real — time, attention, or money — and that they would not perform for a product that does not address their problem.

Three terms the rest of this page uses, with the same wording as the Startup Validation Glossary:

• Problem validation — Evidence that the named customer experiences a problem, with enough frequency and severity to act on. The corresponding test is a problem interview in which the customer describes the problem unprompted and names the current workaround.
• Demand validation — Evidence that the same customer will perform a paid or quasi-paid action — a waitlist signup, a deposit, a pre-order, a paid pilot — for a solution to that problem before the solution exists. This is what "validate demand" means on this page.
• Solution validation — Evidence that the proposed solution actually resolves the problem at a price the customer accepts. This is what happens after a concierge or Wizard-of-Oz pilot succeeds. The full discipline is in MVP Validation.

The three are not interchangeable. A founder who has solved problem validation but not demand validation has evidence the problem exists but not evidence the customer will pay. A founder who has solved demand validation but not solution validation has evidence the customer will pay something for something, but not for the product the founder intends to ship.

Why pre-code validation matters

Steve Blank's Four Steps to the Epiphany (2005) coined the phrase "get out of the building" for a reason. Most early-stage failures trace back to a founder building a solution to a problem the customer did not have, would not pay to solve, or could not be reached at a cost the model supports. Coding before the demand exists is the most expensive way to discover any of those three mistakes — the cost is months of engineering time, not hours of interview time.

The economic argument is sharper than the methodological one. A problem interview costs an hour. A smoke-test landing page costs an afternoon and a small ad spend. A concierge pilot costs a few weeks of the founder's time. A full engineering build costs three to twelve months of one or more engineers' time. The cost ratio between the cheapest demand test and the cheapest build is roughly 1:200. Demand validation is not an academic exercise; it is the cheapest insurance the founder will ever buy.

There is a second-order effect. A founder who has run the five pre-code checks before writing code makes faster engineering decisions during the build. The five checks force a clear answer to "who is this for, what problem does it solve, what is the price, what is the channel, what is the retention loop." An engineer who has those answers ships features that test those answers. An engineer who does not have those answers ships features that guess at them.

The five pre-code evidence checks, in order

The checks below are ordered by what evidence they produce. Skipping a rung produces a test whose result cannot come back negative — which is not a test, it is confirmation with extra steps.

Check 1 — Problem interviews

The cheapest evidence. Five to ten conversations with members of the named customer segment, asking about their life rather than the founder's idea. The discipline comes from Rob Fitzpatrick's The Mom Test (2013): ask about specifics, the past, and the current workaround; never ask "would you buy this."

The decision rule is empirical. If at least half of the interviewees describe the problem unprompted and name a current workaround that costs them time or money, the problem is real enough to keep going. If fewer than half describe it unprompted, the founder is probably solving a problem only they have experienced.

The interview script and the failure modes are in Customer Interview Questions for Startup Validation.

Check 2 — Smoke-test landing page

A single page that describes the planned product in the customer's vocabulary, with one specific call to action: a waitlist signup, a "we'll email you when it launches" form, or a paid deposit. Drive a small amount of paid or community traffic to it and measure the action rate.

The decision rule is empirical. A landing page that converts at 8% or higher on 200 qualified visitors is useful evidence of demand. The same rate on 20 visitors is not — the sample is too small to separate signal from noise. The full mechanics, including what counts as "qualified traffic," are in Landing Page Validation and Fake Door Test Guide.

Check 3 — Concierge or Wizard-of-Oz pilot

A small number of customers receive the planned outcome manually, with the founder (or a contractor) doing the work the product would automate. A Wizard-of-Oz setup is the same idea at the interface level — the customer sees a software-looking surface, but the backend is human.

The decision rule is empirical. If three out of five pilot customers pay the planned price for the manual outcome and continue using it past the first renewal point, demand for the outcome is real. The pilot also surfaces which part of the workflow the customer actually values, which usually differs from the founder's prior. The full discipline is in Concierge MVP Explained.

Check 4 — Pre-order, deposit, or LOI

A direct request for money or a written commitment. A pre-order is a non-refundable deposit tied to a future delivery. An LOI is a written statement of intent to purchase at a named price when the product is ready. Both are stronger than a waitlist because they convert polite interest into a commitment with a cost.

The decision rule is empirical. Five pre-orders or three signed LOIs at the planned price point, from named customers in the named segment, is the cleanest pre-code evidence of demand the founder can produce. The numbers are not universal — a $5,000 B2B LOI and a $5 consumer pre-order are not equivalent — but the principle is the same: someone put skin in the game.

Check 5 — Competitive wedge test

The customer must be reachable. A test that demonstrates the founder can drive a small number of qualified visitors to a landing page, a signup to a waitlist, or a customer to a discovery call, at a cost the eventual pricing model can support, is the fifth check. Without it, every other check is theoretical.

The decision rule is empirical. If the founder can acquire a named customer through a named channel at a customer acquisition cost (CAC) below one-third of the customer's first-year value, the channel is viable. If not, the channel or the pricing has to change before the build. The full ranking of solo-founder-realistic channels is in Distribution Channels Ranked for Solo Founders.

The seven-question build-now-vs-validate-more rule

Before the founder writes a line of code, the seven questions below must have defensible answers. If any answer is "I don't know" or "I assume," the next step is a validation experiment, not a coding sprint.

1. Who is the customer? A specific named role, industry, geography, and use case. Not "small businesses" — "independent property managers in the US with 10–50 units who currently produce monthly reports by hand."
2. What problem do they have? A problem they describe unprompted in at least half of problem interviews, with a current workaround that costs time or money.
3. How much do they currently pay to solve it? A dollar figure, even an estimate. The customer's existing spend is the ceiling on the founder's pricing.
4. What would they pay for the founder's solution? A number, supported by at least one of: a pre-order, a deposit, a signed LOI, or a paid pilot at the planned price.
5. How will the founder reach them? A specific named channel (SEO for a defined query, a defined subreddit, a defined community, a defined cold-outreach segment), with evidence the channel reaches qualified customers at a known CAC.
6. Why would they switch from the current workaround? A specific reason the current solution is broken, slow, expensive, or embarrassing enough that the customer will move.
7. Why would they stay? A specific retention loop — frequency of use, switching cost, network effect, or compounding data — that prevents the customer from leaving after the first use.

If all seven have defensible answers, the build is justified. If any of them does not, the founder's next action is to design the smallest validation experiment that produces the missing answer. The same seven questions also serve as the input to Startup MRI's rule engine — see Startup Validation Methodology for how each question maps to a scoring dimension.

Three labeled hypothetical examples

The examples below are illustrative. The numbers and customer segments are constructed to show what the five checks look like in practice; they are not descriptions of any specific real company. Real founders should adapt the segment, the channel, the price, and the decision rule to their own context.

Example 1 — B2B SaaS (hypothetical)

• Idea. A software tool that automates monthly reporting for independent property managers with 10–50 units.
• Five checks.
  • Problem interviews: five conversations with named property managers. Four describe the reporting burden unprompted. Two mention a current workaround that costs them 4–6 hours per month.
  • Smoke-test landing page: a one-page site describing the planned tool, $200 in targeted Facebook ads, 320 qualified visitors, 26 waitlist signups. Action rate: 8.1%.
  • Concierge pilot: three pilot customers receive a monthly report by email, built by the founder in a shared spreadsheet. Two pay $99 at the end of month one.
  • Pre-order / LOI: two of the three pilots sign an LOI at $99/month for a 12-month commitment once the tool exists.
  • Wedge test: CAC from the Facebook campaign is $7.70 per waitlist signup, which scales to roughly $77 per paying customer at the planned 8% conversion rate.
• Seven-question gate. All seven questions have defensible answers.
• Next decision. Engineering begins. The build is justified by the five checks, not by the founder's enthusiasm.

Example 2 — Consumer app (hypothetical)

• Idea. A daily mindfulness app for adults who have completed a paid meditation course.
• Five checks.
  • Problem interviews: six conversations with members of the segment. Three describe wanting a daily practice but struggling to maintain it; three describe being satisfied with their current course-based routine.
  • Smoke-test landing page: a waitlist page, $150 in targeted Reddit ads, 180 qualified visitors, 9 signups. Action rate: 5.0%.
  • Concierge pilot: a two-week "morning mindfulness" email program sent manually to five recruited subscribers. Three of five open every email; one opens none.
  • Pre-order: none. The customer segment does not pre-order consumer apps at $9.99/month.
  • Wedge test: CAC from the Reddit campaign is $16.70 per waitlist signup, which does not support a $9.99/month subscription at any plausible conversion rate.
• Seven-question gate. Three of the seven questions do not have defensible answers (defensible pricing, retention loop, viable channel).
• Next decision. The founder changes the customer definition to "people who completed a specific paid course in the last 90 days" and re-tests the wedge. If the wedge fails again, the founder stops. Coding is not justified by the current evidence.

Example 3 — Marketplace (hypothetical)

• Idea. A marketplace connecting independent writers with small businesses for one-off content briefs.
• Five checks.
  • Problem interviews: five writer interviews and five small-business interviews. Three writers describe difficulty finding paid work; three small businesses describe difficulty finding writers on demand.
  • Smoke-test landing page: one page per side, $300 in LinkedIn ads, 90 qualified visitors on each side, 12 writer signups and 4 business signups. Asymmetric action rates: 13.3% on the writer side, 4.4% on the business side.
  • Concierge pilot: a six-week manual matching pilot. The founder matches three writer-business pairs by hand. All three transactions complete.
  • Pre-order / LOI: two of three businesses sign an LOI at $500 per brief.
  • Wedge test: LinkedIn CAC is $25 per writer signup and $75 per business signup. Both are above the cost-per-acquisition the model supports at the planned price.
• Seven-question gate. Four of seven questions are partially answered. The wedge test fails for both sides.
• Next decision. The founder changes the channel to community-led growth (writing newsletters and Substack engagement) and re-tests the wedge at lower cost. If the wedge still fails, the founder reconsiders the marketplace model entirely — single-side marketplaces and direct-service businesses both have lower CAC thresholds. Coding is not justified until the wedge works.

Comparison table — which check produces which evidence

The five checks are cumulative. A founder who has done interviews and a landing page but not a concierge pilot has problem and demand evidence but not outcome evidence. A founder who has done all five has the minimum evidence to justify a build.

Common mistakes

The seven failure modes below account for most of the pre-code validation that produces false positives. Each one is a specific way a founder can mistake enthusiasm for demand.

1. Mistaking "would you use this?" for demand. Friends, family, and Twitter followers are polite. They will say yes to be supportive. Rob Fitzpatrick calls this the polite-yes problem. The fix is to measure behavior, not opinion — a signup, a deposit, a paid pilot.
2. Surveying instead of testing. Surveys measure stated preference. Customers cannot accurately predict what they will do next month. The cheapest credible pre-code tests are artifacts the customer uses, not questions the customer answers.
3. Testing the wrong customer. A landing page shared on a founder's personal network measures the founder's network's willingness to act, not the named customer's. The fix is to acquire the visitor through the named channel, not through the founder's audience.
4. Stopping at "people said it was a good idea." Verbal validation is the weakest form of evidence the loop can produce. The minimum behavior that counts is a paid or quasi-paid action.
5. Treating a single pre-order as demand. One pre-order at the planned price is interesting. Three pre-orders from three different members of the named segment is evidence. One pre-order is anecdote. The full discipline is in Willingness to Pay Validation.
6. Skipping the wedge test. A product the customer wants but the founder cannot reach is still a product that fails. Channels are part of the demand test, not a separate workstream after the build.
7. Building because the founder is bored. A founder with two months of runway and a clean five-check evidence pack has a strong reason to build. A founder who is tired of the validation loop does not. Boredom is not validation. The same trap in another form is described in Why Founders Build Before Validating.

Limits of pre-code validation

Pre-code validation narrows the range of things the founder could be wrong about. It does not eliminate that range.

• It cannot prove the solution will work at scale. A concierge pilot with five customers does not predict what happens with five hundred. The build itself is the only test that produces that evidence.
• It cannot prove retention. A customer who pays for the first month may leave at month three. Retention is a separate evidence rung, covered in Product-Market Fit Validation.
• It cannot substitute for ongoing customer discovery. Teresa Torres's Continuous Discovery Habits (2021) argues that customer research is a weekly practice, not a one-time gate. The five pre-code checks are the entry condition for the build; they are not the end of the loop.
• It cannot remove founder judgment. The decision rule for each check is a judgment call, not a formula. A founder who interprets "3 of 5 interviewees describe the problem" as a pass and "2 of 5" as a fail is making the rule in a way that fits the desired outcome. The fix is to write the rule before the data arrives.
• It cannot predict macro conditions. A pre-code check that passes in a bull market may fail in a recession. The customer is real, but the customer's willingness to act is conditional on the environment.

FAQ

What is the cheapest way to validate demand before coding? A problem interview. Five to ten conversations with members of the named customer segment, asking about their current workaround, costs the founder ten hours and no money. It is the cheapest evidence the loop can produce, and it answers the question "does the problem exist." It does not answer the question "will the customer pay."

How many problem interviews do I need? There is no universal number. Five is the minimum to surface a recurring pattern; ten is the minimum to surface a segment that is not the founder's peer group. The discipline is to stop when the new interviews stop producing new information — the saturation point. The full stop rule is in Customer Interview Questions for Startup Validation.

Is a landing page enough to validate demand? A landing page is enough to validate that the customer will perform a low-friction action (a waitlist signup) for the planned solution. It is not enough to validate that the customer will pay. A founder who has run a landing page and no other check has weaker evidence than a founder who has run a landing page and a concierge pilot.

What's the difference between demand validation and willingness-to-pay testing? Demand validation is the broader evidence base: problem, segment, channel, price. Willingness-to-pay testing is the specific check for whether the customer will pay the planned price. A founder can have evidence of demand without evidence of willingness to pay — a waitlist full of customers who will not pay the planned price is not demand for the planned product. The full distinction is in How to Test Whether People Will Pay Before You Build.

Can I skip the concierge pilot if the landing page converts well? You can, but the evidence you have is weaker than you think. A landing page that converts at 8% measures the customer's willingness to perform a low-friction action for a description of the product. It does not measure the customer's willingness to pay for the outcome. A concierge pilot closes that gap by delivering the outcome manually. Skipping it means the founder enters the build without knowing whether the customer values the outcome.

How long should the whole pre-code validation take? For a solo founder with a clear segment, two to six weeks is the realistic range. Five to ten problem interviews in week one. A landing page and small ad spend in weeks two and three. A concierge pilot in weeks four and five. Pre-orders and a wedge test in week six. Faster than that, the founder is probably cutting corners on the checks; slower than that, the founder is probably stuck in research mode and needs to commit to a date.

What if my idea is B2B and the customers are hard to reach? The five checks still apply, but the channels change. Cold email and warm intros replace ads. LinkedIn replaces Reddit. The bar for a successful pilot is lower (three to five customers, not twenty). The bar for a successful pre-order is higher (an LOI at the planned price, not a $9.99 deposit). The full discipline is in How to Validate a B2B Startup Idea Before You Build It.

What should I do if I already started coding? Stop and run the five checks anyway. The cost of two weeks of interviews after a month of coding is much lower than the cost of six more months of coding to discover the customer did not have the problem the founder assumed. The same five checks work as a mid-build diagnostic, not just a pre-build gate.

Summary

Validating demand before coding means producing evidence that a named customer will pay — or behave as if they will pay — for a solution to a problem they actually have. The five pre-code evidence checks, in order, are problem interviews, a smoke-test landing page, a concierge or Wizard-of-Oz pilot, a pre-order or LOI, and a competitive wedge test. The build-now-vs-validate-more rule is a seven-question gate: if any answer is "I don't know," the next step is a validation experiment, not code. The five checks are cumulative; each one produces evidence the others do not. Pre-code validation narrows the range of things the founder could be wrong about, but it does not eliminate that range. A clean five-check pack justifies a build. It does not guarantee success.

Related reading

• How to Validate a Startup Idea Before Building — the broader framework this page sits inside.
• Startup Validation Checklist — the printable checklist version of the same discipline.
• Lean Startup Validation — how the five checks fit inside the Build-Measure-Learn loop.
• MVP Validation — what changes after the pre-code evidence pack is complete.
• Customer Interview Questions for Startup Validation — the interview script for Check 1.
• Landing Page Validation — the mechanics of Check 2.
• Concierge MVP Explained — the mechanics of Check 3.
• How to Test Whether People Will Pay Before You Build — Check 4 at the price-only level.
• Distribution Channels Ranked for Solo Founders — the channel evidence behind Check 5.
• Startup Validation Glossary — definitions for every term used on this page.

Sources

• Steve Blank, Four Steps to the Epiphany (2005) — Customer Development methodology; the "get out of the building" principle that underlies the five checks. Summary at steveblank.com.
• Rob Fitzpatrick, The Mom Test (2013) — the polite-yes problem; behavior-over-opinion as the only honest signal. Summary at momtestbook.com.
• Eric Ries, The Lean Startup (2011) — Build-Measure-Learn loop and the MVP definition that anchors the pre-code validation sequence. Reference at theleanstartup.com.
• Ash Maurya, Running Lean (2012) — the problem-solution fit step that pre-code validation sits inside. Reference at runninglean.com.
• Teresa Torres, Continuous Discovery Habits (2021) — customer research as a weekly practice, not a one-time gate. Reference at continuousdiscoveryhabits.com.
• Strategyzer, Value Proposition Canvas — the fit between the customer's job, pain, and gain and the founder's products and services. Reference at strategyzer.com.
• Y Combinator, How to Plan an MVP — the practical sequence from idea to MVP that aligns with the five checks. Reference at ycombinator.com.

Next action

If the founder has not yet run the five checks, the next action is a single problem interview scheduled this week. Not a survey. Not a landing page. Not a code sprint. A thirty-minute conversation with one member of the named customer segment, asking about their current workaround for the problem the founder's idea is meant to solve. If the founder cannot name the segment well enough to find one interviewee this week, that itself is the most important validation evidence the loop has produced so far.