How to validate an idea before you build it

The goal of validation is not to prove your idea is good. It's to find out whether it's wrong as cheaply as possible. That reframe matters: if you go looking for confirmation you'll find it, because you're motivated, articulate, and your friends are polite. Go looking for the kill shot instead. If the idea survives, you build with real confidence. If it doesn't, you just saved yourself weeks.

1. Say the idea plainly

One sentence: who it's for and what it does for them. Not the architecture, not the feature list. If the sentence needs an "and" to hold together, you have two ideas — pick one. Then add two more sentences: what those people do about the problem today, and why that's not good enough. If you can't answer the "today" question, that's your first research task, not a detail to fill in later.

2. Name the person, not the market

"Developers" is not a customer. "Solo backend engineers who run their own SaaS and dread invoice season" is. The test: could you list five real people or communities that match the description? If you can't point at them, you can't talk to them, and if you can't talk to them, everything downstream is fiction.

3. Map what's already out there

Competitors are evidence a market exists — a blank field is usually a warning, not an opportunity. List what your person uses today, including the unglamorous options: the spreadsheet, the group chat, the "we just live with it". Your opening is wherever the current answers genuinely fail, and switching costs are real: the honest question is never "is mine better?" but "is mine better enough that a busy person would move?"

4. Find the riskiest assumption

Every idea sits on a stack of assumptions: the problem is felt, it's felt often enough to matter, people will change their behavior, they'll pay, you can reach them. Rank them by "if this is false, everything collapses". The one at the top is your riskiest assumption — and it's almost never "can I build it?" You're a builder; of course you can build it. That's precisely why it's tempting to test the wrong assumption first.

5. Design the cheapest test that could kill it

Now design the smallest experiment that could prove that assumption wrong. Five conversations with people who actually have the problem — asking about what they do today, not pitching. A landing page describing the product against a small ad spend. A concierge version where you do the work manually behind the scenes. Decide the threshold before you run it: "if fewer than three of five describe this pain unprompted, I stop." A test you can't fail isn't a test — it's a ritual.

6. Face the evidence

Write down what you learned next to what you predicted, and keep it somewhere that survives — not in chat scrollback. Beware the two classic escapes: polite interest counting as demand ("that's cool, I'd try it" is worth nothing; "can I use it today?" is worth a lot), and moving the goalposts after the results arrive. The evidence is allowed to argue with you. That's what you hired it for.

7. Make the honest call

There are four verdicts, not two: build, when the riskiest assumption survived a real test; validate more, when the evidence is genuinely mixed; pivot, when the problem is real but your solution isn't the answer; and kill, when the evidence says no. Record the verdict and the reasoning — future you will want to know why, and killed ideas have a way of coming back with new context. If the verdict is build, the work you just did isn't overhead: the problem statement, the customer, the evidence, and the scope are the spec your first version comes from.

Where Motriz fits

This is the journey Motriz walks with you — nine founder questions from first context to an honest build-or-stop verdict, with an AI co-founder doing the legwork and every piece of evidence hanging on the journey itself. When the verdict is build, the proven spec hands straight off to coding agents in your real repository. Read the full walkthrough in how Motriz works, or start with why this gap exists at all.