How we validate a product idea before writing a line of code

A founder came to us in November convinced her idea was ready to build, with a full feature list and a launch date already picked out. We spent our first meeting talking her into a two-week validation sprint before writing any code at all, not because we doubted the idea, but because we'd rather find out cheaply if it's wrong than expensively.

Code is the single most expensive way to test whether people actually want something. It takes real time, real money, and it produces a result that's hard to walk away from even when the early signal says you should. We push every founder toward cheaper tests first, specifically to protect them from that sunk-cost trap.

A single page describing the product as if it already exists, with a clear call to action, either a waitlist signup or, better, a real pre-order or deposit. This tests actual intent, not just polite interest, because people click things out of curiosity constantly but rarely hand over an email address or a card number for something they don't genuinely want.

The key is writing the page as if the product is real and specific, not vague and aspirational. A vague pitch gets vague, inflated interest. A specific pitch, with real details about what the product does and doesn't do, gets a much more honest signal about whether this exact thing is something people actually want.

Surveys are easy to run and easy to get misleading results from, because people are generally polite and tend to say a product idea sounds good when asked directly and abstractly. A real conversation, asking someone to describe their current process for solving this problem today, surfaces far more honest and specific signal than any survey question ever does.

We coach founders to ask about current behavior, not hypothetical future behavior. "How do you currently handle this" reveals real pain and real workarounds. "Would you use a product that did X" almost always gets a polite yes regardless of whether that person would ever actually use it once it existed.

For service-shaped ideas especially, we recommend delivering the core value manually first, by hand, before writing any software to automate it. If the idea is a scheduling tool for a specific niche, manually coordinate a handful of real bookings by email and spreadsheet before building anything. This tests the actual value proposition without the sunk cost of a build that might turn out to be solving the wrong problem.

This approach feels slow and unscalable, and that's exactly the point at this stage. Scale is not the question worth answering yet. Whether the core value is real enough that someone will pay or commit real time for it is, and a manual process answers that question just as validly as a polished piece of software would.

Genuine excitement without any commitment, an enthusiastic "I'd definitely use this" with no follow-through when actually asked to sign up, pay, or commit real time, is one of the most common false positives we see founders mistake for validation. Commitment of some kind, money, time, a real introduction to someone else, is the signal that actually matters, because it costs the person something to give.

We ask founders to define, before running any test, what specific action would count as real validation. Deciding this in advance prevents the common trap of moving the goalposts after the fact to make a lukewarm result feel more encouraging than it actually was.

Two to four weeks is usually enough to run a meaningful validation test, longer than that risks losing momentum and market timing, shorter than that risks drawing conclusions from too small or too rushed a sample to actually mean anything. We help founders scope this window explicitly at the start, with a specific decision point at the end rather than an open-ended "let's see how it goes."

This window also forces useful discipline: a founder who can't design a meaningful test in two to four weeks often hasn't yet clarified what they're actually trying to learn, which is itself useful information before committing real development budget to the idea.

Sometimes the test comes back weak, low signup rates, lukewarm conversations, no real commitment from anyone approached. This is a good outcome, even though it doesn't feel like one in the moment, because it's a cheap, fast answer instead of an expensive, slow one arrived at after months of building something nobody wanted enough to commit to.

We help founders in this position separate two very different conclusions: the core idea might be wrong, or the specific positioning and audience tested might be wrong while the underlying idea still has promise. Distinguishing between these two determines whether the next step is a genuine pivot or simply a sharper, better-targeted retest.

Almost every founder we've walked through this process agrees with the logic immediately. Actually doing it is harder, because validation carries a real risk of disappointing news, and building feels like progress in a way that testing doesn't, even when testing is the more useful use of the same two weeks. We name this resistance explicitly when we see it, because naming it tends to loosen its grip.

We remind founders that a discouraging validation result isn't a verdict on them personally, it's information, arriving at the cheapest possible point in the process to receive it. Reframed that way, most founders find the courage to actually run the test rather than skip straight to building on hope alone.

None of this replaces building the actual product eventually. It replaces building it blind, based on conviction alone, when a few weeks of cheap testing could have told you something real before the expensive part even started.

The founders who validate first tend to build better first versions, because they walk into development already knowing what resonated during testing and what didn't, rather than guessing at both simultaneously while the clock and the budget are both running.

We'd rather spend two weeks proving a founder wrong cheaply than spend three months building something a market was never going to want, no matter how well we built it.