There is a specific question this page is about, and it is narrower than validation in general: how do you prove that people will pay, rather than merely say they like your idea?
The reason it deserves its own answer is that the two look identical from the outside. Enthusiasm and demand produce the same emails, the same nodding in calls, the same encouraging comment threads. They only separate at the moment money changes hands, which for most founders is months after the decision to build.
Interest is not payment evidence
Evidence is worth what it cost the other person to give you. Praise costs nothing, so it tells you nothing about a budget. This is not cynicism about people — most of them are being sincere. They simply have no way of knowing what they will do when the price is real, and neither do you until you ask.
Weak evidence
- Likes and shares on a post about the problem.
- Positive comments and encouragement.
- "I would definitely use this."
- Waitlist signups from an untargeted audience who saw the idea in passing.
- Friends and colleagues saying the idea sounds good.
- People requesting features while committing nothing.
Stronger evidence
- Pre-orders at the intended price.
- Refundable deposits — small, but the decision is real.
- Paid pilots, even heavily scoped ones.
- Signed letters of intent, where that is normal in the market.
- A prospect introducing you to the person who controls the budget.
- Someone switching from a paid alternative they already use.
- Repeat usage that is tied to an actual buying decision rather than a free trial.
Ask what it cost the other person: time, money, reputation or political capital inside their organisation. If the answer is nothing, treat it as a hypothesis, not evidence.
The buyer is not always the user
A great deal of false-positive demand comes from asking the right question to the wrong person. The person who feels the pain most sharply is often the person with the least authority to spend money on it.
A practical example. You build a shift-handover tool for hospital ward staff. Nurses try it and love it — it removes twenty minutes of duplicated paperwork per shift, and they say so, warmly and repeatedly. The ward manager, who controls the budget, has three competing requests this quarter and none of them are yours. Even if she agrees, IT security needs to review data handling, procurement needs a supplier record, and the purchase must fit a framework that renews in eleven months.
Nothing here is a rejection. The users genuinely wanted it. But willingness to use is not authority to buy, and if your test only reaches users, you will collect enthusiasm indefinitely.
- Identify who signs, not just who suffers.
- Ask early: if you wanted this, who else would have to say yes?
- Treat an introduction to that person as a stronger signal than any amount of user praise.
- Count procurement, security review and existing contracts as part of the price.
The commitment ladder
Rank every signal you receive by what it cost to give. Each rung is harder to climb than the one below it, and each is worth more than everything below it combined.
- A compliment — free, and therefore uninformative.
- An email signup — a few seconds and an address they may barely use.
- An interview or call — twenty minutes of real time, given willingly.
- A time commitment — sending data, testing a prototype, attending a workshop.
- An introduction to another buyer — they are spending their own credibility.
- A deposit or pre-order — money, before delivery.
- A paid pilot — money, plus internal approval, plus a scope they must justify.
- A repeat purchase or renewal — the only signal that survives contact with reality.
Different businesses live at different rungs. A five-pound consumer product will never generate letters of intent; an enterprise deal will rarely start with a pre-order. The principle holds either way: move one rung up from wherever your current evidence sits, and see whether the signal survives.
Testing the price, not just the idea
A payment test answers several questions at once, and it is worth separating them deliberately rather than reading a single no as a verdict on the whole idea.
- Is the problem painful enough? If people will not spend twenty minutes describing it, they will not spend money solving it.
- Does the proposed price create resistance? Some resistance is healthy; silence usually means the offer was never real to them.
- What kind of objection is it? Price, trust, urgency and value all sound similar and require completely different responses. Ask what would have to be true for this to be an easy yes.
- Are discounts manufacturing demand? A yes at 70 percent off is evidence about the discount, not the product.
- Is the free trial measuring the wrong thing? Trials measure usage. Usage without a purchase decision at the end tells you people enjoy free things.
You are not testing whether the finished product is worth the money. You are testing whether this buyer, at this price, for this problem, will start the process of paying. That test does not require the product to exist.
What to say when you ask for payment
Most payment tests are not failed by the market. They are weakened by the founder in the thirty seconds before the ask. The three common ways to do it: apologising for asking, overexplaining the roadmap until the offer disappears, and volunteering a discount before anyone has objected to the price.
Say the ask plainly, once, and then stop talking. The silence is part of the test.
Based on what you told me, I am testing a paid version of this before I build it fully. The first version will deliver [specific outcome] and cost [realistic price]. I am asking a small number of people to reserve a place with a [refundable deposit / paid pilot / pre-order]. Would you be comfortable committing to that today?
Whatever the answer is, follow it with one question. It costs nothing and it is usually where the real information is.
What would need to change for this to become an easy yes?
In the accountancy example above, the filled-in version reads: the first version will flag every client deadline at risk in the next 30 days and cost 250 GBP per month, and I am asking twelve practice owners to reserve a place with a refundable first month.
How to read the response
- Immediate payment or a deposit: strong evidence. Record the price they accepted, not the price you hoped for.
- Needs approval from someone else: the person in front of you may not be the buyer. Ask to be introduced.
- Wants features that are not central to the outcome: often avoidance rather than a requirement.
- Says later without naming a date or a trigger: weak evidence. A real later has a budget cycle or an event attached.
- Only agrees after a large discount: the original price remains unvalidated, and so does the business model built on it.
- Refuses but explains the objection clearly: useful evidence, and frequently more useful than a soft yes.
- Praises the idea but avoids commitment: interest, not demand. Log it as a compliment and move on.
Do not pressure people, create fake scarcity or imply that the product already exists when it does not. Be explicit about what is being tested, what they receive, when, and whether the payment is refundable. A yes obtained by misleading someone tells you nothing, and it is the one mistake that follows you into launch.
A worked example
The idea. A subscription service that audits small accountancy practices for missed client deadlines, priced at 250 GBP per month.
The encouraging but weak feedback. Eleven practice owners at a regional meetup said missed deadlines were their biggest source of client complaints. Four asked to be kept informed. Two suggested features. Everyone agreed it was a good idea.
The hidden payment assumption. That the owners see missed deadlines as a cost worth 3,000 GBP a year, rather than an irritation they already manage with a spreadsheet and a diligent office manager.
The cheap payment test. A one-page offer at the full 250 GBP per month, with the first month payable up front as a refundable deposit, taken to twelve of those owners in individual conversations over two weeks. No product, no demo — a written description of what would be delivered and when.
Measurable results to look for. How many of the twelve agree to a call; how many ask about price without being prompted; how many pay; how many say the decision belongs to a partner or the practice manager; what the single most common objection is.
The kill criteria, set beforehand. Fewer than two deposits from twelve qualified conversations means stop and rework the offer or the buyer.
The decision. Two deposits and four objections that all mention an existing practice-management system means pivot toward integration rather than replacement. Zero deposits and vague enthusiasm means the irritation is real but nowhere near a 3,000 GBP problem — stop, and go back to interviews.
Kill criteria for willingness to pay
The numbers below are illustrative, not universal — your market, price point and sales cycle will change every one of them. What matters is that you write your own version down before the first conversation, while you can still be honest about it.
- Zero paid pilots after a defined number of qualified conversations — say twenty in a market where a pilot is a normal first step.
- Strong usage interest but no access to a budget holder after repeated asks: you have found users, not customers.
- Deposits appearing only after discounts that would be unsustainable at scale.
- Paid acquisition cost exceeding any plausible estimate of customer value, measured over enough spend to be real rather than noisy.
- Every yes conditional on a feature you cannot build inside your runway.
A criterion without all three is a feeling. "If fewer than two of twelve pay a deposit by the end of the month, I stop and go back to interviews" is a criterion.
Where Failure Forecast fits
Willingness to pay is one dangerous assumption among several. Plenty of ideas clear the payment test and then fail on acquisition cost, on retention, on a regulatory constraint nobody looked up, or on a channel that quietly stops working.
Failure Forecast does not prove demand — nothing except real market behaviour can do that. What it does is identify the payment assumption inside your specific idea, explain the most believable reasons it might fail, and name the test that should happen next. You still have to go and run it.
Find out whether willingness to pay is one of your idea's biggest risks — and what to test first.
Run a free Failure Forecast