Validate an idea before building by testing demand cheaply: talk to real potential users, put up a landing page that measures interest, and try to get a commitment — a signup, a pre-order, a deposit — before you write code. The goal is evidence that people want this badly enough to act, not only polite agreement. If you can't get a cheap yes, a finished product rarely turns that into a real one. Prove demand first.
What's the cheapest way to validate?
Conversations and a landing page. Talk to ten real potential users about the problem — not your solution — and listen for whether it's a real, painful, frequent problem. Then put up a single landing page that describes the offer and measures interest with a signup or waitlist. Both cost almost nothing and take days, not months. If neither produces interest, that's the cheapest "no" you'll ever get, and it just saved you an entire build. Keep the conversations about their problem, not your idea — ask what they do today, what it costs them, and what they've already tried to fix it. The moment you pitch, people get polite; as long as you're asking about their world, you get the truth.
What counts as real validation?
A commitment, not a compliment. "That sounds great" is free; an email signup, a pre-order, a deposit, or a booked call is evidence, because it costs the person something. The strongest signal is someone trying to pay you before the thing fully exists. I weight actions over opinions every time — people are kind in interviews and honest with their wallets and their inbox. Look for the action, not the applause, and trust what people do. A simple ladder of signal, weakest to strongest: a compliment, an email signup, a pre-order or deposit, and someone actively chasing you to get access. The further down that ladder you can get someone to go, the more real the demand — and the more confident you can be that a build is worth funding.
What are the common validation mistakes?
Building first and validating later, asking leading questions, and only talking to friends. Friends and family want to be supportive, so they're a weak signal. Leading questions ("wouldn't it be cool if…") get you the answer you want, not the truth. And the biggest one: skipping validation entirely because building feels like progress. Months of code is the most expensive way to discover nobody wanted it. Cheap tests first, code second. One more trap: treating a single enthusiastic "yes" as proof. One excited person is an anecdote, not a market — look for a repeatable pattern across several real prospects before you commit, because demand that only exists in one inbox usually stays there.
How many people do you need to talk to?
Fewer than you'd think to spot a pattern — usually around ten focused conversations with real potential users is enough to see whether a problem is common, painful, and frequent, or just yours. You're not running a statistical survey; you're listening for the same pain showing up again and again in the words of people who'd actually pay. If eight of ten light up at the problem, that's a strong signal. If you're struggling to even find ten people who have the problem, that's a signal too — and a cheaper one to receive now than after a build.
Can you validate without building anything?
Yes — that's the whole point. The strongest pre-build tests use no product code at all: a landing page that measures signups, a pre-sale or deposit, a waitlist, or a "concierge" test where you deliver the outcome manually for the first few customers. Each one proves real demand with hours of work instead of weeks of building. A demo video or a clickable prototype can stand in for the product while you measure whether people lean in. Only once something real comes back — money, signups, people chasing you — does writing code become the right next spend, and even then you build the smallest version that proves the core.
How do I help validate before a build?
Before scoping an MVP, I push to confirm there's real demand — and if there isn't yet, the cheapest next step is a test, not a build. When the signal is there, I scope the smallest version that proves the core, the way I describe in my SaaS delivery. Validation and a tight MVP are the same instinct: spend the least to learn the most. Build once you have a real reason to.
Related strategy guides
See how to scope an MVP, website, app, or SaaS — what to build first, and MVP vs prototype vs proof of concept.
Testing an idea? Tell me what you're building — I'll help you find the cheapest way to prove it before you spend on code.
