The most expensive thing you can build is the wrong product. Not expensive in the sense of development costs — expensive in the sense of months of your life spent on something that generates no revenue and solves no problem. The sunk cost of a failed product is not just financial. It is the opportunity cost of everything else you could have built during that time.
Validation is the process of confirming, before you build, that real people have the problem you think they have and that they are willing to pay to solve it. It does not eliminate risk. But it dramatically reduces the probability of the most common and most avoidable type of failure.
Why Validation Matters More Than You Think
Most developers and entrepreneurs are optimists. You have to be — building something from scratch requires belief in its eventual success. But optimism about the product idea is not the same as evidence that the market wants it.
The cognitive trap is that the idea feels obvious. Of course people need this. Of course they would pay for it. The founders of every failed SaaS also thought it was obvious. The difference between a good idea and a validated idea is not confidence — it is evidence.
Validation is the mechanism that converts confidence into evidence.
The Cost of Building Without Validation
Consider what development costs before the first paying user. A developer spending six months of evenings on a product spends roughly 500 hours. At a conservative freelance rate of 80 euros per hour, that is 40,000 euros of equivalent value. Even if you never pay yourself, the opportunity cost is real — you could have spent those hours consulting, freelancing, or building a validated product instead.
Beyond time, there is the cost of distraction. Building the wrong thing focuses your attention on the wrong problem for months. By the time you discover it was wrong, the market has moved, your energy has declined, and starting over is harder than it would have been if you had validated first.
None of this means you should never build without certainty. Certainty does not exist in product development. But it does mean that spending two weeks validating before spending six months building is almost always the right trade-off.
What Strong Validation Actually Looks Like
Weak validation: five people said they liked the idea.
Stronger validation: twenty people described the problem independently, using similar words, without being prompted.
Stronger still: people are already paying for imperfect solutions to the same problem.
The strongest validation: someone has agreed to pay in advance for a product that does not exist yet.
The progression from weak to strong validation is a progression from opinion to behaviour. Opinions are cheap and unreliable — people will tell you they like an idea to be polite, or because they find it intellectually interesting, or because they cannot imagine the alternative. Behaviour is expensive and honest — people do not part with money or time without a real reason.
Smoke Tests
A smoke test is the simplest form of validation: describe the product before it exists and measure whether people respond as if they want it.
The name comes from electronics: before powering a new circuit board, you apply low current and watch for smoke. If it burns, you know there is a problem before you have invested in the full test.
The product equivalent is a landing page. Write a clear description of what the product does, who it is for, and what it costs. Include a "Get Early Access" or "Join the Waitlist" button. Drive a small amount of traffic to the page — through Reddit posts, relevant forums, a small ad spend, or a social post — and measure whether anyone clicks.
A meaningful signal is not just page views. It is email signups, waitlist registrations, or click-throughs on a "Buy Now" button that leads to a "not available yet" message. People giving you their email or indicating intent to buy is qualitatively different from people viewing a page and leaving.
Smoke tests are not conclusive. But they tell you whether the description of the product generates genuine interest — which is the earliest possible signal worth having.
Landing Page Tests
A landing page test is a more formalised smoke test with a specific hypothesis. You have identified a problem, you have a proposed solution, and you want to test whether the value proposition lands.
The critical element of a good landing page test is specificity. "A project management tool for freelancers" is a weak hypothesis. "An invoicing and contract tool for freelance developers that connects to their existing code repository and auto-generates invoices from commit logs" is a specific hypothesis that either resonates or it does not.
Vague value propositions produce vague results. Specific ones produce clear answers.
When running a landing page test, the measure is not traffic — it is conversion rate on a meaningful action. If one percent of visitors sign up for the waitlist, that is a signal. If twenty percent do, that is a strong signal. If nobody does, the value proposition is either unclear, wrong, or not reaching the right people.
Using Existing Communities for Research
Before building a landing page, you can validate the problem itself using existing communities — without ever describing your product.
Go to the forums, subreddits, and Slack groups where your target users spend time. Post a question that asks about the problem, not the solution. "For those of you who do client invoicing as a freelance developer — what part of the process frustrates you most?" This produces unfiltered, honest feedback about whether the pain is real, how intense it is, and whether it is actually what you thought.
Responses that are long, detailed, and emotionally engaged are good signals. Short, dismissive, or off-topic responses suggest the problem is not as central as assumed.
This technique also surfaces adjacent problems you had not considered. Someone might answer your invoicing question by saying the contract generation is actually the painful part — and you discover an opportunity you would not have found by building around your original assumption.
Reading App Store Reviews for Gap Signals
If your product idea exists in a category where alternatives already exist, App Store reviews are one of the fastest ways to find specific gaps.
Look at the one-star and two-star reviews of the top-ranked apps in your category. Filter for reviews that describe a specific failure, not just general dissatisfaction. "App crashes on iPad" is a quality complaint, not a gap signal. "Wish there was a way to share invoices with clients without them needing an account" is a gap signal — it describes a workflow the current product does not support, that users want enough to write a review about.
Count how many independent reviewers raise the same gap. If three reviewers mention the same missing feature, it is interesting. If thirty do, across different versions of the app, over multiple years, it is a clear unmet need in a market that already has paying users.
What Strong Validation Looks Like in Practice
Strong validation before building has four components:
Evidence of real pain: multiple independent people describing the same specific problem, without being prompted, using emotionally engaged language.
Evidence of commercial context: people are already paying for imperfect solutions, or they have described how much they currently spend on the manual workaround.
Evidence of willingness to switch: people are dissatisfied with existing tools and have either switched before or are actively looking.
Evidence of intent to pay: signup rates on a landing page above one percent, or pre-sales, or explicit statements of price tolerance in interviews.
No single data point constitutes strong validation. The combination of several — consistent pain, commercial context, switching behaviour, and intent to pay — is what separates a commercially viable opportunity from an interesting hypothesis.
Accelerating Research with Automated Tools
The validation methods described above work, but they take time. Manually scanning Reddit, reading App Store reviews across a dozen apps, and synthesising the findings into a ranked list of opportunity candidates is a multi-day process if done carefully.
Automated market research tools compress that timeline dramatically. ScanTheGap queries Reddit, App Store reviews, Google Trends, and Quora simultaneously — collecting hundreds of real signals in minutes — then applies AI analysis to filter noise, extract genuine pain points, and score each opportunity across the seven factors that distinguish commercially real gaps from interesting-but-unmonetisable ones.
The output is a ranked shortlist of validated market gaps, each with evidence quotes from real users proving the demand exists. You still need to apply your own domain knowledge and run a smoke test before committing to build. But the research that would otherwise take a week now takes ten minutes.
If you are at the stage of exploring what to build next — or looking to validate an idea you already have against market signals — start with a scan. Your first one is free, and it may save you months of building the wrong thing.