Building a product nobody pays for is the most expensive way to find out nobody wants it. You can validate demand before writing a line of code, often within a few weeks and on a small budget. This guide covers what counts as evidence, five ways to collect it and how to decide what to do with the results.
What counts as evidence of demand
Compliments are not evidence. A friend saying “I’d use that” costs them nothing. Look for signals where the person gives something up: time, reputation, data or money. Roughly from strongest to weakest:
- Money: pre-orders, deposits, paid pilots, signed purchase orders.
- Commitment: a letter of intent, a scheduled pilot with named users, an introduction to the person who holds the budget.
- Effort: filling in a long waitlist form, sharing their own data with you, joining a regular feedback call.
- Attention: clicking an ad, opening an email, signing up with only an email address.
Aim for signals near the top of this list. Attention on its own is weak evidence because it is cheap to give.
Start with problem interviews
Before testing a solution, check that the problem exists. Talk to 15 to 20 people who match your intended customer, and ask about what they have done, not what they might do:
- When did this last happen? What did you do about it?
- What did it cost you in time or money?
- What have you tried to fix it? Did you pay for any of those fixes?
- Who else gets involved when it happens?
Hold back your idea until the end of the conversation. If people have not tried to solve the problem, have not spent money on it and cannot remember the last time it happened, demand is likely weak, however enthusiastic they sound.
Write down the exact phrases people use. They become your landing page copy later.
Five low-cost ways to validate demand
1. A landing page with a real ask
Build a single page that describes the outcome, the price and one clear action: “reserve with a ₹500 deposit”, “book a paid pilot” or “join the waitlist”. Send targeted traffic to it through ads or outreach and measure the share of visitors who take the action. A page that shows a price tells you more than a “coming soon” page.
2. A concierge version
Deliver the result by hand for a few customers. Say a Kochi founder wants to build a meal-planning app for people managing diabetes. Instead of building the app, she sends weekly plans over WhatsApp to 20 paying users, prepared in a spreadsheet. If most renew after a month, the app has a reason to exist. If they drop off, she has learned that cheaply.
3. Pre-sales and letters of intent
For B2B ideas, show a clickable prototype or a slide-based demo and ask for a paid pilot or a signed letter of intent that includes a price. A buyer who signs a non-binding letter but will not introduce you to their budget holder is giving a weaker signal than it first appears.
4. Search and marketplace data
Check whether people already search for the problem or for existing solutions. Keyword tools and marketplace search suggestions give a rough sense of interest. Reviews of competing products show what buyers complain about, which tells you where a better product could win.
5. A smoke test in a channel you already own
If you already have an audience or a product, add a button or menu item for the new offer and count clicks, with a message explaining that it is coming soon. Or offer the new product to your email list with a pre-order link.
Set pass and fail rules before you validate demand
Decide in advance what result means “go”. Without that, any outcome can be read as encouraging. Here are examples of rules a team might set:
- Problem: at least half the interviewees describe the problem without prompting and have already spent money or time trying to solve it.
- Willingness to pay: a minimum number of deposits or paid pilots by a fixed date, for example three paid pilots within six weeks for a B2B product.
- Retention: concierge customers renew or keep using the service after the first month.
These are illustrations, not industry benchmarks. Set your own thresholds from how many customers you need and what each one is worth to you.
Reading the results
If the signals are strong across several tests, build the smallest version that delivers the result customers have already paid for. If they are mixed, change one variable, often the customer segment or the price, and run the test again. If they are still weak after two rounds, stop or pick a different problem. Stopping here is a good outcome, because you keep the money you would have spent on development.
When you do build, scope the first version tightly around what the tests showed. Our app development and SaaS projects start with a written scope for this reason; a first app version typically takes 8 to 14 weeks, so it pays to be sure about the problem first.
Mistakes to avoid
- Asking leading questions such as “would you use an app that…?”
- Counting sign-ups from friends, family and other founders.
- Testing with a free offer and treating sign-ups as willingness to pay.
- Running tests without a deadline, so they never end.
- Building a full MVP as the first test.
If you have an idea and want help designing the tests, book a short call with us.
Frequently asked questions
How many customer interviews do I need to validate an idea?
Fifteen to twenty interviews with people who match your target customer usually show whether a problem is common and painful. If the answers are still very different after twenty, your customer definition is probably too broad. Interviews only test the problem, so follow them with a test that asks people for money or a firm commitment.
Is a waitlist enough to prove demand?
Usually not. Joining a waitlist with an email address costs very little, so many sign-ups never become customers. A waitlist becomes stronger evidence when it asks for effort or money, such as a deposit, a detailed form or a booked call. Measure how many people on the list respond when you ask them to pay.
What is the difference between validating demand and building an MVP?
Validation tests whether people want the result enough to commit, often with no product at all. An MVP is the smallest working product that delivers that result. Validate first, so the MVP is built for a problem and a price you have evidence for. That usually keeps the first build smaller and cheaper.