Should your MVP prove demand with a landing page before you build the product?
A practical guide for founders deciding whether to test demand before building. It explains how to validate the problem with interviews, landing pages and other lightweight proof, what each method tells you, and when the result is strong enough to justify a build.
On this page
WhyWhatWaysSignalsCompareMistakesDecideNextHelpIn short
- Start with the problem, not the feature list.
- Use interviews to learn what people actually struggle with.
- Use a landing page or waitlist to test interest before you code.
- Treat early interest carefully; clicks are not the same as demand.
- Move to a build only when you have enough evidence to reduce risk.
Founders often feel pressure to start building quickly. That can be useful when the market need is already clear. But if you are still unsure whether people actually want the idea, a full build is usually the wrong first move.
A better first step is to test the problem and the demand with something lighter: customer interviews, a simple landing page, a waitlist, a mockup or a very small prototype. The point is not to impress people. It is to learn whether the problem is real, whether the offer makes sense and whether enough people care to justify the next round of work.
That is the right way to think about an MVP: not as the product itself, but as the smallest honest test of whether the product should exist at all.
Why validation comes before build
Business guidance from the UK government describes market research as the best way to test and validate an idea, and notes that an MVP is the most basic version of a business you can bring to market. The same guidance frames an MVP as a cost-effective way to test the market, gather feedback and improve the plan. That matters because many product failures are not technical failures. They are examples of building the wrong thing, too soon, for too few people.
If you are a founder or early product team, your first question is rarely “Can we build it?” It is usually “Should we build it?” A lighter validation step helps answer that without spending months on engineering work or design polish.
What to test first
- 1
The problem
Do people recognise the pain point you think they have? If they describe a different problem, your idea may need reframing before any build starts.
- 2
The audience
Who feels the problem strongly enough to care now? A vague audience is hard to test and hard to serve.
- 3
The promise
What outcome are you offering, in plain language? The clearer the promise, the easier it is to test honestly.
- 4
The demand signal
Would people take a next step now, such as joining a waitlist, booking a call or answering follow-up questions? That signal matters more than general approval.
Low-cost ways to test demand
Customer interviews
Best when you need to understand the problem deeply. Interviews help you hear the language people use, the workarounds they already rely on and what they would value instead. Intercom’s product guidance shows that interviews, combined with simple artefacts, can reveal what customers really need before development goes much further.
Landing page or waitlist
Best when you want a quick market signal. A page can explain the problem, the promise and the next step. If people sign up, request access or ask follow-up questions, you have some evidence of interest. But you still need to test whether that interest survives contact with a real offer.
Mockup or storyboard
Best when the idea is hard to explain in words. A visual can make the workflow concrete and help people react to something specific instead of guessing what you mean.
Tiny prototype
Best when you need feedback on the shape of the experience. MaRS notes that validating requirements with customers, testers and engineers before the product is built helps ensure the result reflects what people actually need. A tiny prototype can support that learning without becoming a full product.
Which signals matter most
Not every positive response means the idea is working. A founder needs to separate curiosity from commitment. Someone saying “that sounds useful” is weaker evidence than someone joining a waitlist, agreeing to a follow-up conversation or asking what it would cost.
Stronger signals
People give specific pain points, volunteer their current workaround, return for follow-up, share budget context, or ask when they can try it.Weaker signals
Friends saying they like it, broad praise with no detail, social likes, or generic comments that avoid the real problem.Good questions
What would you use instead today? How do you solve this now? What makes the current approach frustrating? What would make change worth the effort?Bad questions
Would you buy this? Do you like it? Would you recommend it? These often invite polite answers rather than useful ones.How each test reduces risk
| Method | What it proves | Main limitation |
|---|---|---|
| Interviews | Whether the problem is real and painful enough to matter | People may describe needs that do not translate into action |
| Landing page | Whether the message and offer attract attention | Clicks do not prove usage or payment |
| Waitlist | Whether someone will take a small commitment | A waitlist can be inflated by weak interest |
| Prototype | Whether the workflow feels understandable | A prototype can overstate readiness if it looks finished |
Common ways validation goes wrong
- Building too much before asking anyone outside your team.
- Testing the feature idea but not the business problem.
- Using friends and colleagues as the main source of evidence.
- Treating page traffic as demand without checking intent.
- Writing copy that is too vague to test a real decision.
- Ignoring what happens after the first expression of interest.
When evidence is enough to build
There is no universal threshold. You need enough evidence to make the next build decision less risky, not risk-free. That usually means you have seen a consistent problem, a clear audience, a believable promise and at least one strong demand signal from people outside your network.
0 of 5 complete
If those criteria are missing, the honest answer may be to keep validating, reposition the idea or stop. That is not failure. It is how you avoid spending time and money on a product nobody needed.
Practical next steps
- 1
Write the problem in one sentence
Describe the pain point from the customer’s point of view, not your product idea.
- 2
Talk to five to ten potential users
Look for repeated wording, repeated frustration and repeated workarounds. Keep the conversation focused on the current process.
- 3
Choose one lightweight test
Pick the smallest option that can answer the next question: a landing page, a waitlist, a mockup or a tiny prototype.
- 4
Define the signal in advance
Decide what counts as useful evidence before you launch the test. That prevents moving the goalposts later.
- 5
Review the result honestly
If the evidence is weak, change the idea or stop. If it is strong, move to a focused MVP with a narrow scope.
When specialist support helps
You do not need a consultancy to run every validation step. Many founders can do interviews and a simple landing page themselves. Specialist help becomes useful when the idea depends on technical complexity, integrations, automation, data handling or a careful first build after validation.
For example, if the next step is a scoped MVP, a prototype with real workflows, or a product that needs secure data handling from day one, support from a product and engineering team can help you turn the learning into something buildable without overcommitting too early. The need for help should come from the complexity of the decision, not from pressure to build faster.
About the author
Nixim Team, Product Engineering
Practical guidance from Nixim on building software, working with AI and running dependable cloud systems.