Your first product should test an assumption, not prove your idea is brilliant.
Introduction
A founder has a promising idea, finds a developer, spends months building the product, launches and discovers that customers do not care enough to use it.
This is one of the most expensive mistakes in startup building. The better question is not whether you should build before validating. It is what is the cheapest version of the idea you can build to learn whether the market wants it?
The Deeper Challenge
Validation is often misunderstood as asking people whether they like an idea. That is not validation.
A potential customer saying, “I would definitely use this” costs them nothing. Real validation comes from behaviour: signing up, paying, sharing contact details, joining a waitlist, testing a prototype or committing resources.
For a Nigerian founder operating with limited capital, this distinction matters. Every naira spent building an untested feature is capital that could have been used to discover what customers actually need.
Build Less, Learn Faster
You do not need a fully developed app to test demand.
A fintech founder might begin with a landing page and manual onboarding. An e-commerce startup could test demand through a simple catalogue and WhatsApp ordering. A SaaS founder could demonstrate a clickable prototype before writing the underlying software.
AI and no-code tools make these experiments faster and cheaper, allowing founders to test assumptions before committing heavily to engineering.
The objective is not to avoid building. It is to delay expensive building until the evidence improves.
Common Mistakes
The biggest mistake is confusing product feedback with market validation. Friends, colleagues and fellow founders may provide useful opinions, but they are rarely representative customers.
Another mistake is trying to validate everything at once. Start with the riskiest assumption: Will customers pay? Will they switch? Is the problem painful enough?
Founders also sometimes build an MVP that is simply a smaller version of the final product. An MVP should instead be the minimum experiment capable of producing meaningful evidence.
A Practical Framework: TEST
Use the TEST model before committing significant resources:
- T – Target: Identify the specific customer and problem.
- E – Evidence: Define what customer behaviour would prove demand.
- S – Small experiment: Test the assumption with the cheapest credible method.
- T – Track: Measure behaviour and decide whether to proceed, change direction or stop.
Actionable Recommendations
Interview potential customers, but observe what they actually do.
Create a landing page, prototype, waitlist, manual service or pilot before building complex technology. Ask for a real commitment where appropriate payment, registration, referral or time.
Set a clear validation threshold before starting the experiment. This prevents founders from moving the goalposts when results are disappointing.
Then use what you learn to prioritise the product roadmap.
Conclusion
The strongest founders are not necessarily those who build fastest. They are those who learn fastest without wasting capital.
For MarkHack, this principle reflects a broader belief in practical innovation: founders, marketers and technology leaders create stronger businesses when experimentation comes before assumption and evidence informs execution.
Build when building creates learning. Build more when the market gives you a reason to.