How to Validate a Business Idea Before Building It

We've already written the tactical playbook for validating an idea — the actual steps, in order, from writing down your assumptions to running a demand test. If you haven't read that one yet, start there for the how.

This one is about something slightly different: which validation philosophy actually fits the idea you're sitting on, because "validate before you build" means different things depending on who you ask — and the differences matter more than most founders realize.

The classic Lean Startup approach

The version most people have half-absorbed from startup culture: build a minimum viable product, get it in front of users, measure, learn, repeat. It's a genuinely good framework — the problem is that "minimum" quietly turns into "a working product" for most people, because building still feels more productive than talking to strangers. MVP validation done honestly is powerful. MVP validation used as an excuse to start coding immediately is just building with extra steps.

Noah Kagan's approach: prove the money first

Noah Kagan's philosophy, laid out in Million Dollar Weekend, strips this down further and gets more uncomfortable, on purpose. His core move: get someone to pay you — or at least commit to paying you — before you've built anything at all. Not a survey. Not a "would you be interested." An actual dollar, or a real, specific commitment.

His famous version of this is what's often called the coffee shop test: walk up to strangers, describe your idea in one sentence, and ask them directly if they'd pay for it. Most founders never do this, because it's genuinely uncomfortable to hear "no" to your face. That discomfort is the point — it's exactly the signal you need before you spend a month building something nobody wanted.

The underlying idea isn't really about coffee shops. It's this: the fastest, cheapest way to find out if an idea works is to ask for the sale before you've earned it, and see what happens. If you can't get a stranger to say yes to a rough pitch, a polished product isn't going to fix that.

Where this gets hard for AI-first builders specifically

Here's the tension AI tools have quietly created: building has gotten so fast that skipping validation now feels almost reasonable. You can go from idea to working prototype in an afternoon, which makes "just build it and see" tempting in a way it never was before.

That speed is real leverage — and it's also exactly why the Kagan approach matters more now, not less. A prototype you built in an afternoon that nobody asked for is still a wasted afternoon, just a cheaper one than before. The question was never really "can you build it fast." It was always "does anyone want it" — and that question still requires a real conversation, or a real dollar, no matter how fast your tools have gotten.

How Waymaker operationalizes this instead of just preaching it

This is the exact reasoning behind Waymaker's validation-first structure — Cameron and the Validate phase exist specifically so you can't accidentally skip from "I have an idea" straight to "I built a thing," the way it's now dangerously easy to do. Before you build, Market Radar and Customer Simulation give you a fast first pass at whether the market and the message hold up. But the honest version of the Kagan test — a real ask, to a real stranger — is still something only you can do. No tool replaces that conversation. It just makes sure you don't skip it.

Which philosophy should you actually use?

Use Lean Startup thinking when your idea genuinely needs a working thing to get honest feedback — some products can't be evaluated as a pitch alone. Use the Kagan approach for almost everything else, especially service-based and simpler product ideas, because it's faster, cheaper, and more honest than an MVP that took a weekend and a small mountain of AI-generated code to build.

Either way, the rule that survives both philosophies is the same one: get real signal from a real stranger before you fall in love with what you've built.

---

Want the tactical steps, not just the philosophy? Read the full validation playbook, or bring your idea straight to Cameron and pressure-test it before you write a line of code. Meet Cameron here.