What should you validate before building an MVP? Start with proof, not features
A practical guide for founders deciding what to test before building an MVP: prove the problem is real, speak to potential customers, check whether the idea is worth paying for, and use a small build to decide whether to continue, pivot or stop.
On this page
WhyTestHowScopeNextIn short
- Validate the problem before the product.
- Speak to real prospective customers, not just friendly contacts.
- Test willingness to pay, not only interest.
- Use the MVP to learn one decision, not everything at once.
- Stop or change direction quickly if the evidence is weak.
The most expensive mistake in early product work is building too much before you know whether real customers care enough to pay. A good MVP is not a small version of a big dream. It is a test of the assumptions that matter most.
UK guidance and startup pricing advice point in the same direction: research the market, speak to people who represent future customers, and check whether the problem is real before investing heavily in build work. If you get that wrong, an elegant product can still miss the market. If you get it right, a modest build can save months of wasted effort.
Why validation comes first
An MVP is useful only if it answers a real business question. For most founders, that question is not “Can we build it?” but “Should we build it at all?” The aim is to reduce uncertainty before you spend on design, engineering and ongoing support.
Business.gov.uk recommends researching the market, including who the customers are, what they need, what competitors charge, and what prospective customers think the idea is worth paying for. Stripe makes the same basic point in different language: idea validation should come before heavy investment, because market research helps confirm whether a real problem exists and whether people would pay to solve it.
The assumptions to test first
- 1
Does the problem really exist?
Start with the pain, not the solution. Ask whether people currently struggle with this task, what they do today, how often it happens and what it costs them in time, money or missed opportunities.
- 2
Is it a problem they care enough about to solve now?
Some issues are real but not urgent. A product only has a chance if the buyer sees enough value to make the change now, not “someday”.
- 3
Would they pay for a solution?
This is a separate question from whether they say the idea is interesting. Stripe notes that willingness to pay should be tested using behaviour, because customers are often poor at predicting what they will actually pay.
- 4
Can you reach and serve the buyer?
You may have a good idea in a market that is hard to access. Check whether you know how to find the buyer, explain the value clearly and deliver the product without creating operational drag.
- 5
What is the smallest outcome worth proving?
A first release should prove one meaningful outcome, not every feature on your wish list. If you cannot define the outcome, the build is too vague.
How to test willingness to pay early
There are several practical ways to test payment intent without building the full product. The best choice depends on how mature the idea is and how easy it is to describe clearly.
Customer conversations
Talk to people who fit your intended buyer profile. Ask about the last time they faced the problem, what they used instead, what it cost them and what a better outcome would be worth. Do not lead them towards your preferred answer.
Behavioural tests
Use actions rather than opinions where possible. Examples include a deposit, a paid pilot, a waiting list with pricing, or a pilot proposal that asks the customer to commit time or budget.
The point is not to force an immediate sale. It is to see whether the idea survives contact with reality. A conversation may reveal that the problem is too small, the buyer is someone else, or the price point is unrealistic. That is useful learning, even if it is disappointing.
What people say
“That sounds useful.” “We would probably use it.” “We might pay for that later.”
What people do
Agree a pilot, share real data, introduce you to the person who owns the problem, or commit budget and a timeline.
Use both, but trust behaviour more than enthusiasm. A polite conversation can help shape the offer, but it is not proof of demand.
What the MVP should and should not do
Once the problem and payment signals look credible, define the smallest build that can test the central assumption. Business.gov.uk describes an MVP as the most basic version of a business that reaches market with essential features only, so you can test, get feedback and iterate without overspending.
Should do
Solve one narrow use case. Collect enough evidence to judge the idea. Be easy to explain. Produce a clear yes/no or continue/change/stop decision.Should not do
Try to serve every user type. Add features because they are easy to build. Hide uncertainty behind polish. Become a permanent half-finished product.Keep in mind
A small MVP is not an excuse for poor quality. It still needs a clear workflow, basic reliability and enough usability for the target user to give honest feedback.0 of 6 complete
What to do after the first test
At the end of the test, make the next step explicit. Either the evidence is strong enough to continue, or it is not. Ambiguity is expensive because it can keep weak ideas alive for too long.
- 1
Continue
If users show clear pain, the price feels believable and the MVP is being used, you may have enough evidence to extend the product carefully.
- 2
Change
If the problem is real but the offer is wrong, adjust the buyer, the workflow or the pricing before building more.
- 3
Stop
If customers do not care enough, do not buy, or cannot explain why they would switch, stopping early protects time and budget for better opportunities.
This approach is especially useful for founders working with a limited budget or a tight window to prove traction. It keeps the conversation focused on value, not vanity features. If the next step is a more structured build, a specialist partner can help scope the smallest credible release, but only after the core assumptions have been tested.
About the author
Nixim Team, Product Engineering
Practical guidance from Nixim on building software, working with AI and running dependable cloud systems.