Most digital products don't fail because they're badly built. They fail because nobody needed them as much as the founder believed. That's the expensive way to find out — months into development, with the budget already spent. Validating before you build is how you find out cheap.
This is the guide we use at Cambalache Studio when a founder comes to us with an idea and wants to know whether it's worth investing in an MVP, or whether the hypothesis needs more work first.
Validating Isn't Asking Your Friends
The most common mistake is confusing "everyone loved the idea" with validation. It costs nothing for someone to think your idea is good — it costs something for them to pay, sign up, or give you their time. Real validation measures behavior, not opinions.
A weak signal: "Awesome, let me know when you launch." A strong signal: someone leaves their email, puts down a deposit, or asks to use it today even half-finished.
The Three Questions You Need to Answer
Before you build, you need evidence on three things:
- Does the problem exist and actually hurt? People are already spending time, money, or energy solving it in some clunky way (spreadsheets, WhatsApp, manual processes).
- Is your solution clearly better? Not a little better — better enough that it's worth the switching cost of a new habit.
- Is there a way to reach those people? A channel for acquiring users that doesn't depend on going viral.
If you don't have evidence on all three, the MVP is premature.
Experiments You Can Run This Week
None of these require development. All of them generate real signals:
| Experiment | What it measures | Cost |
|---|---|---|
| Landing page with waitlist | Demand / intent | Low |
| Problem interviews (10–15) | Whether the pain is real | Just time |
| Pre-sale or deposit | Willingness to pay | Low |
| "Wizard of Oz" (manual process behind the scenes) | Real usage of the service | Medium |
| Paid ad to a landing page | Acquisition cost | Ad budget |
The most underrated one is the pre-sale. If someone transfers you even a small deposit for something that doesn't exist yet, that's the strongest validation you can get.
Interviews: Ask About the Past, Not the Future
When you run interviews, don't ask "would you use this?" People lie to avoid looking bad. Ask about past behavior instead:
- When was the last time you had this problem?
- What did you do to solve it?
- What did it cost you (time or money)?
- What have you tried that didn't work?
The answers to those questions can't be faked, and they tell you whether the pain is real.
When to Move From Experiment to MVP
You should build when validation starts to become the bottleneck on your end: the waitlist keeps growing, people are asking when they can pay, the manual process can't keep up anymore. That's the moment the MVP stops being a bet and becomes a response to demand that already exists.
If you've reached that point, the next step is scoping it properly. We wrote about that in how to put together your product brief, and if you want to see concrete investment ranges, check out how much an MVP costs.
What It Costs Not to Validate
Building without validating first isn't expensive only in money: it's expensive in team time, in the sprints spent on the wrong hypothesis, and in the credibility you burn with early users when you hand them something that doesn't serve them.
A properly scoped MVP already has its own cost and its own timeline — the concrete ranges are in how much an MVP costs. Skipping validation doesn't avoid that cost: it just means you end up paying it twice, because the first version targeted the wrong problem. What you lose there isn't only the development budget — it's the weeks of research, design, and sprints you spent building the wrong hypothesis, plus the time you or your team didn't spend looking for the signal that actually mattered.
There's also a cost that never shows up on an invoice: credibility. Shipping something nobody asked for spends down the patience of your early users and of the team that built it. If there's a second attempt, it starts with less trust than the first one did.
Validating doesn't remove that risk, but it surfaces it before it costs months of development. If the idea doesn't pass validation, you find out by spending a few days and a small ad budget — not the full cycle of building, launching, and only then discovering nobody was waiting on the other side.