Validating Your Idea Before You Build

Dana spent eight months building a scheduling app for hair salons before she showed it to a single stylist. She had the logic for recurring appointments, a booking calendar, and a payment flow. When she finally demoed it to her first salon owner, the response was polite and immediate: "We already use Vagaro for this, and switching would mean re-training my whole staff." Dana had built a genuinely good product for a problem almost nobody was actively trying to solve differently. The eight months weren't wasted because the code was bad, they were wasted because she skipped the one step that would have told her this before she wrote a line of it.

This is the most common founder mistake, and it isn't laziness or incompetence. It's a natural instinct: building feels like progress, and asking strangers whether they'd pay for something feels like exposure. But the two produce very different information. Writing code tells you whether you can build the thing. Talking to potential customers, or better, getting them to commit money, tells you whether the thing should exist.

Validation is the discipline of answering one question as cheaply and quickly as possible before you commit real time and money: will people actually pay for this? Not "would they use it if it were free and perfect," not "is this a good idea in theory," but will a specific person hand over money, or its equivalent in effort, for the specific thing you're proposing to build. Everything in this lesson is a set of tools for getting an honest answer to that question fast, so that if the answer is no, you find out in weeks instead of months, with a few hundred dollars spent instead of a year of your life.

Not all positive signals are equally meaningful, and confusing a weak signal for a strong one is how founders talk themselves into building things nobody wants. When Dana first pitched her scheduling idea to friends and former coworkers, six out of seven said some version of "that sounds really useful." She took that as validation. It wasn't. It was politeness, and politeness is nearly free to give.

The hierarchy below runs from weakest to strongest evidence, and the pattern underneath it is simple: the more a signal costs the person giving it, in money, time, or reputational risk, the more it tells you. Words are free. Clicking a button is nearly free. Committing to a future purchase costs a little thought. Paying costs real money now. Move down this table as fast as you can, because every step filters out the people who were just being nice.

Once you accept that talk is cheap, the next question is practical: what do you actually do this week to get real evidence? Below are five tested methods, roughly ordered from least to most demanding, each suited to a different kind of idea.

The smoke test, or landing page test, is the fastest option for a software or app idea. Build a simple page describing the product as if it already existed, with a clear "Get early access" or "Pre-order now" button, and send a small amount of real traffic to it, through a few relevant online communities or a small ad budget. What you're measuring isn't traffic, it's conversion: out of the people who saw the offer, how many cared enough to hand over an email address or a card number. A landing page that converts at 2 to 5 percent from cold traffic is a real signal. One that converts at 0.1 percent, even with thousands of visitors, is telling you something you'd rather hear now than after six months of development.

The concierge MVP works when the product is really a service wrapped in future software. Before Marcus built any matching algorithm for his idea, pairing small landscaping crews with homeowners who needed one-off yard work, he spent three weeks doing the matching himself: texting homeowners, calling three crews, and coordinating the job by hand. He charged a small fee for the match. This told him, before writing a line of code, exactly what homeowners actually cared about (same-week availability, not lowest price) and exactly where crews got frustrated (no-shows, not the app experience). Automating a workflow you understand from doing it by hand is a very different, much cheaper project than automating a guess.

The Wizard of Oz test looks like a finished product to the customer, while humans quietly do the work behind the curtain. A common version: a chatbot that appears fully automated but is actually answered by a person typing responses in real time for the first fifty users. This validates the experience and the willingness to use it, without spending months building the automation that might turn out to be the wrong automation.

Pre-sales mean selling the product before it exists and collecting a deposit or full payment up front. This is close to mandatory for anything physical, since manufacturing a product speculatively is expensive and hard to undo. A founder designing a specialty backpack should be able to describe it precisely (materials, capacity, price) and take fifty pre-orders before ordering a single unit from a factory. If fifty strangers won't put down a deposit on a clear description, a factory-ready sample usually won't change their minds either, this is the fastest route to tier four of the hierarchy above.

Customer interviews, run with one specific question, are the right starting point when you're not yet sure the problem is even real. Run 10 to 15 conversations built around one prompt: "Tell me about the last time you dealt with [the problem you think you're solving]. What did you actually do about it?" The goal is not to pitch your idea, it's to listen for whether the pain shows up unprompted, how people currently cope (often with a clumsy workaround, a spreadsheet, or simply tolerating the problem), and how much it costs them in time or money. If fifteen people struggle to even recall the last time the problem happened, the problem may not be as painful as it feels from the inside.

The five methods above aren't a menu to pick from at random, they map fairly cleanly onto two questions: how confident are you that the problem is real, and what kind of product are you building? A founder who is still guessing at the problem should not skip straight to pre-orders, and a founder with a validated problem and a physical product should not spend a month on customer interviews they've effectively already run. Work through the branches below to land on the method that fits where you actually are.

Even once you're running the right validation method, it's easy to misread the results, especially when you want the idea to work. A room full of nodding heads and a stack of specific, unprompted commitments can feel similar in the moment. They aren't. The table below contrasts what real interest tends to look like against what polite interest tends to look like, drawn from the same conversation or the same test.

The clearest tell is often the third row: what someone is already doing about the problem. If a would-be customer has cobbled together a workaround, a shared spreadsheet, an inbox full of manually forwarded orders, a duct-taped combination of two other tools, that's a person who has already proven, with their own time, that the problem is worth solving. Someone who has never bothered to work around the problem at all is telling you, whether they realize it or not, that it doesn't hurt enough yet.

Validation has a natural failure mode of its own: turning into permanent research instead of a bounded test. It's possible to interview people for a year and never build anything, which avoids the risk of failing but guarantees the cost of never finding out.

"Active effort" matters as much as the deadline. A landing page that sat untouched with no traffic sent to it for a month didn't fail validation, it never ran the test. Set the clock only once you've actually put the offer in front of people: posted in the communities where your target customer spends time, emailed the list you built, or had the fifteen conversations. If, after genuinely trying, the number of paying customers or serious commitments is still zero or one, that's real information about the idea as it currently stands, not a reason to try the same approach for another month.