Validate an idea by collecting evidence of behavior, not opinions. Interview ten to fifteen people about how they handle the problem today, put a clear offer on a landing page, deliver the result by hand for a few customers, ask for money or a signed commitment, and test a clickable prototype of the solution. You are ready to pay for development when specific people have given up time, money or reputation to get the problem solved. Until then, building is the expensive option.
Why validate before an MVP
An MVP answers one question well: does this solution work for people who have this problem? It is a poor instrument for finding out whether the problem exists or whether anyone will pay, because it takes months and a five-figure budget to return an answer. The methods below answer those earlier questions in weeks for a few hundred dollars. Our step-by-step guide to building an MVP treats validation as step one of seven; this article is that step in full.
There are three separate risks, and each method tests a different one:
- Problem risk. Do enough people have this problem, often enough, at enough cost?
- Demand risk. Will they act, and pay, to have it solved?
- Solution risk. Does your particular approach make sense to them?
A fourth, technical risk, applies when the open question is whether something can be built at all. That calls for a proof of concept, explained in the difference between an MVP, a prototype and a proof of concept.
The five methods at a glance
| Method | Risk it tests | Typical time | Typical cash cost | Strongest signal it can produce |
|---|---|---|---|---|
| Problem interviews | Problem | 2–3 weeks | Close to zero | People already spend time or money on a workaround |
| Landing page and waitlist | Demand, messaging, reach | 1–2 weeks to set up, 2–4 to run | $0–$300 for tools, plus any ad spend you choose | Sign-ups who reply and take a call afterwards |
| Concierge or manual service | Demand, workflow | 3–6 weeks | Mostly your time | Customers pay and come back for a second round |
| Pre-sales and letters of intent | Willingness to pay | 2–4 weeks | Close to zero | Money received, or a signed intent from the budget holder |
| Clickable prototype test | Solution | 1–3 weeks | $0 if you design it yourself, a few thousand dollars if a designer does | Users complete the core task unaided and ask when it will be available |
The costs are planning estimates. You rarely need all five. Interviews plus one commitment test (concierge or pre-sales) is the minimum that deserves to be called validation.
1. Problem interviews
Talk to ten to fifteen people from one narrowly defined segment. "Small business owners" is too wide. "Owners of independent physiotherapy clinics with two to five practitioners" is a segment.
The discipline is to ask about the past and never to pitch. People are unreliable about what they would do and accurate about what they did.
| Ask | Avoid |
|---|---|
| Tell me about the last time this happened. | Would you use an app that solved this? |
| What did you do about it? What did that cost you? | Do you think this is a good idea? |
| What have you tried? Why did you stop using it? | How much would you pay for this? |
| Who else is involved when this goes wrong? | Would your team find this useful? |
| Where does this rank among the problems you dealt with this month? | Is this a big problem for you? |
Listen for a workaround. A spreadsheet maintained every week, a part-time assistant hired to handle it, a tool they pay for and complain about: each proves the problem is worth effort to them. No workaround usually means the problem is an irritation and not a priority.
Write notes immediately afterwards and keep a simple tally: how many had the problem in the last month, how many have a workaround, how many spend money on it. Patterns across fifteen conversations are evidence. One enthusiastic conversation is an anecdote.
2. Landing page and waitlist
One page: who it is for, the outcome you promise, how it works in three lines, the price if you are prepared to show one, and one call to action. Then send the right people to it through communities where your segment gathers, direct messages, a small search or social ad budget, or your interviewees' referrals.
Be careful about what a waitlist proves. An email address costs the visitor nothing, so the count on its own is weak evidence. Make it stronger:
- Ask one or two qualifying questions on sign-up (role, company size, current tool). People who complete them are more serious, and you learn who is responding.
- Email every sign-up within a day and ask for a fifteen-minute call. The share who reply is a better measure than the sign-up count.
- Show the price. Interest that survives a visible price is worth several times as much as interest without one.
- Test two versions of the promise. Which problem statement draws the response tells you how customers frame the problem.
Be honest on the page. If the product does not exist, say it is in development and that they are joining an early-access list. Never take payment for something described as available when it is not.
A landing page is a good job for a site builder, not for custom development. Our comparison of no-code tools and custom code explains where each belongs.
3. Concierge or manual service
Deliver the outcome by hand for three to ten customers, using email, spreadsheets, video calls and existing tools. If the idea is software that produces monthly compliance reports for small landlords, produce the reports yourself and send them. The customer receives the result; the "product" is you.
This is slow and does not scale, and that is the point. Within a few weeks you learn what the real workflow is, which steps customers care about, what they are willing to pay and which parts deserve automating first. Charge for it, even at a discount. A free pilot measures politeness. A paid one measures demand.
A related form is the manual back end: customers use a simple form or page, and you perform the processing by hand behind it. Be open about turnaround times and do not imply automation that does not exist.
Concierge tests suit services, B2B workflows, marketplaces (match the first twenty transactions by hand) and data or reporting products. They suit products less where the value depends on instant response or a large network.
4. Pre-sales and letters of intent
The strongest evidence is money changing hands before the product exists. Forms it can take:
- Pre-orders or deposits with a clear refund promise and a realistic delivery date.
- A paid pilot agreed with a business customer: a fixed fee for a defined period once the first version is ready.
- A discounted founding-customer plan paid upfront in exchange for early access and influence over the roadmap.
- A letter of intent: a short signed statement that the company intends to buy at a stated price if the product does what is described.
Letters of intent are usually non-binding, so judge them by who signs. One signed by the person who controls the budget, naming a price, is meaningful. One signed by an enthusiastic employee without purchasing authority is a compliment on letterhead. For wording, refund terms and tax treatment of pre-payments, ask a lawyer or accountant in your jurisdiction; this article is not legal advice.
Asking for money feels premature to most first-time founders. It is the fastest way to find out whether "this is great" means "I will buy it".
5. Clickable prototype tests
Once the problem and the demand look real, test whether your solution makes sense. A clickable prototype is a set of designed screens linked together in a design tool. It looks like the product and contains no code.
Run five to eight sessions with people from your segment. Give each a task ("you have a new booking request; deal with it"), then stay quiet and watch. Do not explain the interface. Record where they hesitate, what they expect to happen and what they look for that is not there.
Good outcomes: most participants finish the core task without help, describe the product back to you accurately, and ask about availability or price without prompting. Poor outcomes: confusion about what the product is for, or polite praise followed by no questions at all.
The prototype has a second use. Attached to a brief, it makes development quotes considerably more precise, because the team is pricing screens they can see.
Signal and noise
| Noise: feels good, proves little | Signal: costs the other person something |
|---|---|
| "Great idea, I would definitely use that" | Describes a recent occasion in detail and what it cost them |
| Friends and family signing up | Strangers from the target segment signing up |
| Waitlist size | Waitlist members who reply, take a call or answer qualifying questions |
| Social media likes and followers | Introductions to colleagues or to the budget holder |
| Survey answers about future behavior | An existing paid or labor-intensive workaround |
| "Send me something when it is ready" | A deposit, a pre-order, a paid pilot, a signed letter of intent |
| Praise for the prototype's appearance | Completing the core task unaided, then asking when and how much |
| An advisor or investor liking the space | A customer giving you access to their data, process or team |
The rule behind the table: evidence is whatever costs the other person time, money or reputation. Everything else is encouragement.
Two biases to watch in yourself. Confirmation bias: you will remember the enthusiastic interviews and explain away the flat ones, which is why the written tally matters. And sunk cost: the longer you have carried the idea, the harder a negative result is to accept. Decide what result would make you stop before you run each test.
A simple validation scorecard
Score each line 0, 1 or 2 using only evidence you have actually collected. The thresholds are rules of thumb meant to force an honest conversation, not a scientific instrument.
| Criterion | 0 | 1 | 2 |
|---|---|---|---|
| Problem frequency and cost | Rare or trivial | Regular but tolerable | Frequent, and costs real money or hours |
| Existing workaround | None; they live with it | An improvised free workaround | They pay for a tool or a person to handle it |
| Reach | Interviewees came only through personal contacts | You can find more with effort | You have a repeatable channel to the segment |
| Commitment | Compliments only | Time given: repeat calls, introductions, data shared | Money paid or a letter of intent from a budget holder |
| Solution fit | Not tested, or users were confused | Users completed the task with help | Users completed the task unaided and asked for access |
| Price viability | Unknown, or the acceptable price cannot sustain the business | A plausible price was discussed without objection | Someone agreed to a price that works for your model |
| Total (out of 12) | What it suggests |
|---|---|
| 9–12, with Commitment at 1 or more | Build a narrow MVP for the segment you tested |
| 5–8 | Keep testing. Work on the lowest-scoring line next |
| 0–4 | Change the segment or the problem before spending more |
Example: a founder testing scheduling software for mobile dog groomers scores frequency 2, workaround 2, reach 1, commitment 1, solution fit 2 and price 1. The total is 2 + 2 + 1 + 1 + 2 + 1 = 9. That is enough to build a narrow first version, with the next validation effort aimed at pre-sales to lift the commitment score.
A high total with Commitment at zero is the classic trap: a well-understood problem that nobody will pay to solve. Do not build on it.
When you are ready to build
- You can name at least five specific people or companies who have the problem and want it solved
- You can describe how they handle it today and what that costs them
- At least a few have committed money, a signed intent or significant time
- You know the one job the first version must do, and it fits in a sentence
- You have a way to reach the next fifty people like them
- You have run the workflow by hand or tested a prototype, so the first release is based on observation
- You have a budget for the build and for at least three months of iteration afterwards
When most of these are true, the next steps are scoping and choosing who builds. The MVP cost breakdown shows how to estimate a budget from effort and rates, and if you have no technical partner, read building an MVP without a technical co-founder. BBR's MVP development service starts from a scoped roadmap with agreed acceptance criteria, and validation evidence is the best input that roadmap can have.
When not to build yet
- Your only evidence is enthusiasm from people who know you.
- Every interview described a different problem.
- Nobody accepted an offer to pay, pre-order or sign, and you have not found out why.
- You cannot say how you will reach customers beyond your own network.
- The build would consume all your funds, leaving nothing for changes after launch. What those months involve is covered in what to do in the first 90 days after an MVP launch.
None of these means the idea is dead. They mean the cheapest next step is another test, not a development contract. A few more weeks of validation costs far less than a product built for a customer who turns out not to exist.