How I Validate Product Ideas Before Writing Code
The most expensive code is the code you didn't need. Here's the product discovery I run before a line gets written, so the build targets the real risk.
The most expensive code in any product is the code you didn't need to write. Not because it was slow to build — because it answered a question nobody was asking. Most of the discovery I do before a build exists to avoid exactly that.
Start with the riskiest assumption, not the easiest screen
Every product idea is a stack of assumptions. People want this. They'll do the work to use it. They'll trust it with their data. They'll pay. The instinct is to build the easiest part first — the login screen, the settings page — because it feels like progress. It isn't. It's motion.
The discipline is to find the one assumption that, if it's wrong, sinks the whole thing, and aim the first build directly at it. If the risk is "will anyone trust an AI to do this," you don't build the dashboard first. You build the thing that tests trust. Everything else is deferrable.
The questions before the build
Who exactly, and what job?
Not a demographic — a person with a specific job they're trying to get done. What are they using today, and where does it fail them? Vague users produce vague products.
What's the smallest thing that proves it?
The minimum artifact that turns the riskiest assumption from a guess into evidence. Sometimes that's a prototype. Sometimes it's a single working flow. Rarely is it the whole app.
What does "it worked" look like?
Defined before the build, not rationalised after. If you can't say what outcome would prove the idea, you're not ready to build it — you're ready to keep thinking.
Prototype the hard part, not the whole part
A Figma prototype of the genuinely risky flow tells you more in two days than a half-built app tells you in two weeks. You put the hard interaction in front of someone and watch where they hesitate. The parts everyone already knows how to build — auth, settings, CRUD — don't need validating. The part nobody has done before does.
This is where being both a product person and an engineer pays off: I can tell which assumptions are actually risky to build versus which just feel scary, and scope the validation to the real ones.
Scope to the riskiest assumption first. That's how an MVP stays minimal instead of quietly becoming the whole product.
Then the scope doc
Discovery ends in writing: a scope doc that says what gets built, in what order, why that order, and what each stage is meant to prove. It's short, it's honest about tradeoffs, and it exists before the first commit. The point isn't ceremony — it's that you and I agree on what we're testing before we spend the budget testing it.
If you've got an idea and you want someone who'll pressure-test it before building it — not just take the order — that's how I start every engagement. The booking link is below.
Build the AI layer you'd be proud to ship.
If your roadmap has voice, copilots, RAG, or agentic flows on it, the booking link below is the right move. 30 minutes, no pitch, straight answer on whether I can help.