Somewhere right now, someone is building a product nobody asked for. I know, because I was that person. I spent four months and roughly €6,000 building a scheduling tool for freelancers before I discovered that the freelancers I'd imagined were perfectly happy with a shared Google Calendar and a €9 app they'd already paid for. Nobody bought. Not one person.
That failure taught me more about how to validate a startup idea before launching than any guide I'd read beforehand. The uncomfortable truth is that most founders don't validate — they seek confirmation. They ask friends, get polite nods, and treat encouragement as evidence. It isn't. Validation is a measurement exercise, and if you're not willing to be proven wrong, you'll be proven wrong by the market instead, at ten times the cost.
Key Takeaways
- Validation is about testing assumptions, not collecting encouragement — the two feel similar and are not.
- You need defined kill/go thresholds before you run any test, or you'll rationalise whatever result you get.
- Customer interviews work only when you ask about past behaviour, never about hypothetical future purchases.
- A landing page with a real payment or deposit step beats a hundred conversations. Intent costs nothing; commitment costs something.
- Roughly a third of the idea validation work happens before you write a single line of code — and that third is where most of the leverage sits.
What idea validation actually means (and what it doesn't)
Here's the thing: "validate" has quietly become a synonym for "ask around." That's a shame, because it hides the only definition that matters. Validation means reducing uncertainty about three specific things — does the problem hurt enough, will people pay, and can you reach them at a cost that leaves margin — using evidence that costs you less than building the thing would.
Notice what's absent from that definition. It says nothing about passion, nothing about how clever the technology is, nothing about whether your mum likes the name. All three of those have sunk more projects than bad code ever has.
The two questions you are really answering
Strip everything back and you're answering two questions. First: is this problem important enough that someone will change their behaviour to solve it? Second: can I find that someone repeatedly, and cheaply? A startup that answers yes to the first and no to the second is a hobby with paperwork.
When to evaluate an idea for a startup, most people start with market size spreadsheets. I'd argue the opposite order works better. Talk to ten real humans first. If the problem is real, the spreadsheet becomes a formality. If it isn't, the spreadsheet's precision was always theatre.
The confirmation trap
My scheduling-tool mistake had a specific shape, and I see it constantly in founders who email me. I asked questions designed to be answered yes. "Would you use a tool that syncs your calendar with your invoices?" Everyone said yes. Of course they did — it's free to be agreeable.
Real talk: a yes to a hypothetical is worth nothing. A yes that costs the respondent twenty minutes of their time, or €10 of their money, is worth something. That's the entire principle behind everything below.
The steps to validating an idea, in the order that saves you money
The sequence matters more than the individual tactics. Run them out of order and you'll spend money testing demand for something you haven't confirmed anyone wants. Here's the order I now use, and the one I recommend to anyone who asks.
Step 1 — problem interviews (about 2 weeks)
Fifteen to twenty conversations with people who match your target profile. Not friends. Not other founders. People who have the problem. Keep each one to twenty-five minutes and ask about what they did last time the problem came up, not what they'd do in an imaginary future.
Useful questions sound like this:
- "Walk me through the last time this happened. What did you do?"
- "What did that cost you — in money, time, or stress?"
- "What have you already tried to fix it?"
- "Who else did you involve?" (Reveals whether it's a solo annoyance or an organisational one.)
- "Did you pay for anything?" — the single most predictive question in the whole set.
Listen for workarounds. A spreadsheet someone built themselves and maintains monthly is a louder buying signal than any enthusiasm you'll hear out loud. When I was testing a bookkeeping idea, the strongest signal wasn't a compliment — it was a woman showing me a twelve-tab spreadsheet her accountant had built and hated.
Step 2 — competitor and substitute teardown (3–4 days)
Sign up for every competitor you can find. Pay for one. Use it for a week. Note exactly where it makes you swear at the screen. That frustration list is your product brief, and it's more valuable than any feature brainstorm.
Don't forget substitutes. "Nobody does this" almost always means "people solve it with a spreadsheet, a WhatsApp group, or an intern." Those are your real competitors, and they're free. Beating free requires being dramatically better at one specific job, not slightly better at five.
Step 3 — the commitment test (3–4 weeks)
This is where most people stop short, and it's the step that actually decides things. Build a one-page site. Describe the outcome, not the features. Add a call to action that requires something real: a deposit, a pre-order, a scheduled call with a card on file, a signed letter of intent from a business buyer.
What counts as a signal? My working thresholds, refined across a handful of projects:
| Test type | Weak signal | Worth continuing | Strong |
|---|---|---|---|
| Problem interviews | Polite interest | 8 of 20 describe the same specific pain unprompted | Several already pay for a workaround |
| Landing page (warm traffic) | Under 5% click the CTA | 10–15% click through | Over 20% click, and 3–5% complete a paid step |
| Pre-sale / deposit | "Sounds great, keep me posted" | 5–10 paying commitments from 100 targeted contacts | 20+ commitments, or one signed B2B contract |
| Concierge pilot (manual delivery) | Users churn after one use | Half return within two weeks unprompted | They start asking to pay for more |
Those aren't laws of physics. They're starting points I've calibrated against my own results, and you should recalibrate against yours. The point is having a number before you look at the data.
Step 4 — deliver it by hand (2–4 weeks)
Deliver the value manually to five to ten users. No product, no app, no automation. If you're proposing a meal-planning service, plan the meals yourself over email. If it's a recruiting tool, do the sourcing by hand. It's exhausting and unglamorous, and it will teach you more about the real job to be done than a year of building.
This step also tests something no survey can: whether you actually enjoy the work. I've watched founders discover during a concierge pilot that they hated the operational side of their own idea. Better to find that out in week six than year two.
How do I validate my business idea without wasting months?
Set a timebox and a spend cap, and hold both. My rule: no more than eight weeks and no more than roughly 5% of what building the full product would cost before you have a decision. If the evidence isn't there by then, more time rarely produces it — it usually produces a sunk-cost argument instead.
Write the kill criteria down before you start. Mine, verbatim, from the last project: "If fewer than 5 of 100 targeted contacts commit to a paid pilot by day 45, I stop." Having it in writing meant I couldn't negotiate with myself at day 44. Which, let me tell you, I tried to do.
What about AI idea validators?
Tools that score a startup idea — the various validator apps that generate a market analysis from a paragraph of description — are fine for one thing: structuring your own thinking. They'll produce a competitor list and a set of assumptions you hadn't articulated. That's useful as a checklist.
What they cannot do is tell you whether anyone will pay. A model that has never spoken to your customer will confidently generate a total addressable market, a risk register, and a go-to-market plan, all of which are plausible and none of which is evidence. Use them to draft your interview script. Don't use them to decide. I've seen a founder show up with a 30-page AI-generated validation report and no conversations. He had done the paperwork of validation without the validation.
How long should validation take?
Six to ten weeks for most software ideas, longer if you're selling to enterprises with procurement cycles. Anything under four weeks is usually a survey, not a validation. Anything over four months usually means you're avoiding a decision you already sense the answer to.
How to evaluate an idea for a startup when the signals are mixed
They will be mixed. That's the normal state, and it's why people write long documents instead of deciding. Here's the filter I use when the data is muddy.
The reversibility question
Ask whether the next step is reversible. Signing a two-year office lease isn't; running a paid pilot with ten customers is. Lean toward the reversible experiment when you're unsure, every single time. You can afford many reversible mistakes and roughly one irreversible one.
Segment the signal
A 6% conversion rate overall might be 2% from one channel and 22% from another. The average hides the answer. Break every result down by where the person came from and what they already use. Twice now, an apparently mediocre result turned out to contain one small, extremely promising segment I'd have missed if I'd only looked at the total.
Three failure signals worth taking seriously
- You're explaining the value every time. If nobody grasps the benefit without a pitch, the problem isn't marketing.
- People are enthusiastic but immobile. Compliments without a changed behaviour are noise.
- Your best prospects are the ones who understand it least. Usually means you're solving a problem for a buyer who isn't the one holding the budget.
And a fourth, self-directed one: if you find yourself avoiding a particular test because you're afraid of the answer, that's the test to run first.
Should I validate with a survey?
Surveys are weak for demand and decent for segmentation. Asking "would you buy this?" produces meaningless data — people overstate intent massively. Asking "what do you currently use for this, and what does it cost you?" produces usable data. Keep surveys short, and use them to find people to interview, not to reach conclusions.
Do I need a prototype before validating?
No. You need something people can react to — a mockup, a landing page, a hand-drawn flow, or a manual service. I've seen a paper prototype sell a paid pilot. The prototype exists to make the offer concrete, not to prove you can build it.
The decision nobody wants to make
The hardest part of validating a startup idea isn't the research. It's the moment the numbers come back and they're not good, and you have to choose between your spreadsheet and your attachment to the idea.
My scheduling tool failed every threshold I now use. Eight weeks in, I had four sign-ups, two of them from people I knew. I kept going for another two months anyway, because the alternative was admitting I'd spent €6,000 learning something I could have learned for €200.
Here's what I'd want you to take from that. The purpose of validation isn't to prove your idea works. It's to find out cheaply whether it does, so that the money and years you eventually spend go somewhere they can actually compound. A killed idea isn't a loss. A three-year build against no demand is.
So before you write the first line of code: pick your number, write it down, and give yourself a deadline. Then let the evidence speak, even when you'd rather it didn't. Especially then.
