solving validation · will anyone actually pay?

The Distribution Chain, link 0 of 7. The gate before distribution: whether people have the problem and will pay to solve it, how to tell real intent from politeness, and three ways to find out before you build.

This essay is part of the Solving Distribution chain framework. Validation sits just before the chain begins, and it gatekeeps everything after it.

The Distribution Chain: Link 0 of 7

Before you write a line of code, before you spend a week on a landing page headline (Link 2), before you spend a euro testing acquisition channels (Link 5), you have to pass through one unforgiving gate:

Do real human beings actually have this problem, and is their pain acute enough that they will give you money or attention to solve it?

This is Link 0 of the chain: Validation.

Most founders treat distribution as a marketing problem that starts after a product is built. They spend six months heads-down, launch to crickets, and diagnose the failure as a distribution issue. We just need to figure out marketing.

No. You built something nobody wanted enough to pay for.

Distribution amplifies demand that already exists. It cannot conjure demand out of thin air. Trying to distribute an unvalidated product is like flooring the accelerator in a car with no engine: a lot of noise, a lot of fuel, no movement.

What Validation Actually Answers

Validation tests willingness-to-pay and pain intensity before you incur the cost of building and scaling. It answers two questions:

The Hair-on-Fire Question: is this problem painful enough that the target user is actively trying to solve it right now, with hacky, imperfect workarounds?
The Skin-in-the-Game Question: will they commit scarce resources, money or a card on file or a signed letter of intent, before the product is finished?

Compliments are free. Validation is expensive. Real validation only happens when a prospect takes on real risk or real friction to get access to what you are building.

How to Diagnose a Broken Link 0

A failure here happens when you confuse polite interest with commercial intent.

Quantitative Signals

High waitlist volume, zero pre-orders: a thousand people submitted an email address, but ask for a small refundable deposit or a pre-order and conversion falls to zero.
No budget anywhere: prospects in discovery calls praise the concept, then say “we don’t have budget for this right now” or “we’d use it if it were free”.
Ghosting at the pricing conversation: users happily talk about their problems for an hour, then disappear the moment you send a proposal or a contract.

Qualitative Signals

The “that’s cool” reaction: you demo a prototype and people smile and say “that’s really neat”, rather than leaning forward and asking when they can buy it.
No active workarounds: ask how they handle the problem today and they admit they mostly don’t. If nobody is solving this with spreadsheets, manual labour or a hacky script, the pain is not acute enough.
Scope creep as a condition to buy: “I’ll buy it once you add X, Y and Z.” They still won’t buy when you add X, Y and Z.

Why Validation Breaks (Root Causes)

Why do founders spend months building products nobody buys? Three psychological traps.

1. Asking Hypothetical Questions

Founders ask potential users things like “would you buy a tool that automatically generates reports?” People want to be polite, so they say yes, definitely. Hypothetical questions produce hypothetical commitments. You have to ask about past behaviour and money already spent, never about future promises.

2. Confusing Traffic with Intent

Ten thousand views on a Hacker News post feels like validation. Curiosity is not commercial intent, and upvotes are not dollars.

3. Building to Avoid Rejection

Writing code feels productive and safe inside an editor. Rejection on a sales call feels awful. So founders keep building features as a way to postpone the moment of truth, which is asking a real customer for real money.

The Fix: 3 Tactical Playbooks for Link 0

If you are starting something new, or you suspect your current product has a demand problem, freeze development and run these three.

Tactic 1: The Smoke Test Landing Page

Test commercial intent before you write the backend.

Build a high-intent page. State the exact problem, the proposed solution, and clear pricing options.
Put a high-friction call to action on it. Not a newsletter box. A button that says “Pre-order” or “Start 14-day trial”.
Measure the purchase-intent click. When someone clicks the paid button, show them an honest modal: “We’re rolling out access to our next cohort of 50 teams. Enter your email to lock in early pricing.”

The difference between the two kinds of signal is the whole test:

[ Weak signal ] Entered an email for the newsletter. No skin in the game.
[ Strong signal ] Clicked “Buy now” on a €49/mo plan before discovering access is gated.

If 5% to 10% of targeted visitors click a paid call to action, you have evidence of intent. If nobody clicks it, the demand is not there yet.

Tactic 2: Run Mom Test Interviews

Never ask users whether your idea is good. Ask about their past actions and current spending, following Rob Fitzpatrick’s Mom Test principles:

Flawed hypothetical question (bad)	Behavioural validation question (good)
Do you think managing invoices is hard?	How did you handle invoicing last month? Walk me through it.
Would you pay €50/mo for a tool that automates X?	How much money or time did you spend trying to solve X last year?
Would you use an AI SQL generator?	What tools have you already bought or built to help your team write SQL?

You are looking for evidence of money spent, time lost, or an existing hacky workaround. If they haven’t spent money or effort on this problem in the past, they will not pay for your solution in the future.

Tactic 3: The Concierge Method

Before you build the automated version, deliver the service by hand.

Building an AI invoice processor? Take invoices by email and parse them into a spreadsheet yourself, overnight.
Building an automated report generator? Write the reports manually for your first five customers.

Three reasons this works. It tests whether customers care about the outcome regardless of the technology behind it. It lets you charge money on day one. And it teaches you the exact edge cases you will need to handle when you finally automate.

Real-World Example: How Buffer Validated Demand

When Joel Gascoigne had the idea for Buffer, he did not spend months building a social media scheduling engine. He built a two-page website.

Page one explained what Buffer did and listed three pricing tiers. Click a paid tier and you landed on page two, which said Buffer wasn’t quite ready yet, and asked for an email address so they could let you know when it was.

Once enough people clicked through on the paid plans, Joel knew he had something people had already tried to buy. Only then did he write the first line of code.

AngelList started the same way, as an email newsletter and a manual introduction service run out of Gmail by Naval Ravikant and Babak Nivi, long before it became a software platform.

The Takeaway: Validation Earns the Right to Build

Validation is the gatekeeper for the entire chain. Passing it gives you the confidence, the clarity and the early revenue you need to work through every link that follows:

Link 0, Validation: prove people will pay for the solution.
Link 1, Retention: make sure your first users stay.
Link 2, Messaging: say it clearly enough that the right people get it in three seconds.
Link 3, Activation: get sign-ups to the aha moment fast.
Link 4, Conversion: turn activated users into paying customers.
Link 5, Channel: find the one platform where your buyers live.
Link 6, Reach: scale that channel safely.
Link 7, Referral: turn linear growth into a compounding loop.

Stop guessing. Find the broken link in your chain, fix it, and move to the next one.

One link at a time.