How to validate a startup idea before you build anything

The reason validation goes wrong is almost never laziness. It is that the pleasant version of validation — conversations about the idea — produces encouraging answers regardless of whether the idea is any good. People are agreeable, hypothetical spending is free, and nobody wants to tell a visibly excited founder that they would not pay. So the interview says yes, the market later says no, and the gap between those two answers gets paid for in months of building.

The fix is to stop asking about the future and start looking for what has already happened. Every idea worth building leaves traces before you arrive: someone is spending money badly, hacking together a workaround, complaining in public, or searching for a solution that does not exist yet. Those traces are checkable. Opinions are not.

Test 1: find the money that is already moving

The single strongest signal is existing spend on the problem — not on your solution, on the problem. If people currently pay a person, a tool, an agency, or a competitor to deal with this, the problem is real and budgeted. Your job shrinks from "create demand" to "redirect it," which is a categorically easier job.

So ask: what does someone with this problem pay for today? Options include a direct competitor, a general-purpose tool being bent into shape (spreadsheets, Airtable, Notion), a freelancer, an agency, an internal hire, or hours of their own time. Any of those is a budget line. If the honest answer is "nothing, they just live with it," that is not automatically fatal, but you have now signed up for the hardest kind of startup — one that has to convince people a problem is worth solving before convincing them your solution solves it.

The trap: a competitor's existence is often read as bad news. Usually it is the best news in the exercise. Zero competitors in a market where people have money means either you are very early or, far more often, the market has already tried and quietly rejected this. Before you celebrate an empty field, check whether it is empty because nobody has looked or because everybody who looked left.

Test 2: hunt for workarounds

A workaround is the clearest evidence a problem hurts. When people build ugly manual processes — a spreadsheet with seven tabs, a Zapier chain nobody understands, a weekly two-hour ritual of copy-pasting — they are telling you they will pay for relief, because they are already paying in time. Nobody maintains a workaround for a problem they do not care about.

Workarounds are also visible in public if you know where to look: forum and community threads where someone asks "how do you all handle X," templates and scripts people share with each other, tutorial content that exists only because a proper tool does not, and job listings for a role whose whole description is your product's feature list. That last one is a strong tell — a company paying salary to do manually what you propose to automate has already priced the problem for you.

Write down, verbatim, the words people use to describe the workaround. That language is worth more than any positioning brainstorm, because it is what they will type into a search box.

Test 3: identify the buying trigger

Problems get tolerated for years and then, one day, get solved. What changed? That change is the buying trigger, and if you cannot name it, your product may be genuinely useful and still never get bought — because nothing ever makes it urgent.

Triggers are usually events, not states: a new hire, a funding round, a compliance deadline, a failed audit, a system that finally broke, a competitor's move, a new regulation, hitting a size where the manual way collapses. "They realise they should be more strategic" is not a trigger. "Their bookkeeper quits three weeks before end of financial year" is.

Test yourself on this one specifically: describe the last day in the life of a customer before they buy. If you can tell that story concretely, you know your trigger, and you also know where to be found — because triggers are searchable. If you cannot, that is the gap to research next, and it is worth more than another feature.

Test 4: make one real ask

Everything above can be done from a desk with public information, which is why it comes first. But at some point you need one signal that costs the other person something. Only costly signals discriminate, because free approval is available for any idea.

Costly, in rough order of strength: a payment, a deposit, a signed letter of intent, a scheduled meeting with the actual budget holder, an introduction to a colleague, a documented commitment to trial. Weak signals — worth roughly nothing on their own: "this sounds great," an email address on a waitlist, a like, a friend's enthusiasm, "definitely let me know when it launches."

Note that a pre-order is not the only costly ask. If your buyer cannot pay before the thing exists, ask for the next most expensive thing they can give, which is usually calendar time with the person who controls the budget. A prospect who moves a meeting to make room for you has told you more than fifty waitlist signups did.

Test 5: check the economics arithmetic, roughly

Validation is not only "do they want it" but "does the shape of this work at all." You do not need a financial model. You need one honest pass at three numbers: what a customer is plausibly worth over their lifetime, what it plausibly costs to reach one, and how many customers exist to reach.

The failure mode here is not being wrong — every early estimate is wrong. It is discovering, after building, that the arithmetic never could have worked: a product priced at a level where you would need to acquire customers for almost nothing, or a total addressable market so small that success looks like a modest salary. Both are fine if chosen deliberately. Both are painful when discovered by accident.

Use ranges, write down the assumption behind each number, and pay attention to which single assumption the whole thing depends on. That is the one to test next.

What order to run these in

Cheapest and most public first: existing spend, then workarounds, then triggers — all of which you can research without asking anyone's permission. These three tell you whether there is a market at all. Only then spend your scarce credibility on the real ask, because by that point you can describe the problem in the buyer's own language, which is what makes a stranger take the conversation seriously.

Stop early when the evidence is clearly negative. That is the entire return on validation: not the green light, which you will find a way to justify anyway, but the cheap red light that saves six months. An idea killed in a week for a documented reason is a good outcome, and you can reuse most of the research on the next one.

Where this goes wrong

• Asking whether people like the idea. Liking is free. Ask what they do today, what it costs them, and what they last paid to fix it.
• Interviewing the wrong person. The user's enthusiasm does not survive contact with the budget holder's indifference. Find out early who signs.
• Treating zero competitors as a win. More often it means the market was tried and abandoned. Check which.
• Counting waitlist signups as demand. A free signup costs nothing, so it discriminates nothing. Cheap signals inflate confidence without raising it.
• Validating the solution instead of the problem. People can be wrong about whether your approach works while being completely right that the problem hurts. Confirm the pain before defending the design.
• Building to get validation. If you catch yourself saying "I need to build it before people can judge," check whether the four tests above have actually been run. Usually they have not, because building feels like progress and research feels like delay.
• Never defining what would kill it. Decide in advance which finding would make you stop. Otherwise every result reads as encouraging.

What good looks like

At the end of validation you should be able to say, in specific terms: here is who has the problem, here is what they pay today to deal with it, here is the workaround I found in public and the words they used to describe it, here is the event that makes them go looking, here is the one costly commitment I got, and here is the assumption that would sink this if it is wrong. Six concrete answers, each traceable to something you can point at. If your answers instead take the form of "I think" and "people would probably," you have an idea you like — which is where everyone starts, but it is not yet validation.