Someone pitched me last month: an app that helps dog owners find pet-friendly cafés. They'd already registered the domain, sketched the logo, and spent two weekends on a Figma prototype. When I asked how many dog owners had told them this was a real problem, they went quiet. Then: "Well, everyone I've mentioned it to thinks it's a nice idea."
That's not validation. That's polite nodding from friends. And it happens constantly — I've done it myself. In 2021 I burned four months and roughly €6,000 of savings building a scheduling tool for freelance translators before a single one of them told me, honestly, that they were fine with the spreadsheet they already had.
So here's what I've learned since about how to validate a startup idea before building, structured as a sequence of tests you can run without writing production code, plus the thresholds I use to decide whether to keep going or kill it.
Key Takeaways
- Validation is two separate jobs: proving the problem is painful enough that people already spend money or time on it, then proving your solution is the one they'd pick.
- Compliments are not data. Pre-orders, signed letters of intent, calendar bookings, and repeated unprompted follow-ups are data.
- A useful default: 20–30 problem interviews per segment before you commit, and stop early if the pattern is clear after 12.
- B2B and B2C validation look almost nothing alike — different cycle lengths, different buyers, different signals.
- Plan to spend 4–8 weeks and a few hundred euros, not thousands, before you write a line of product code.
- You're not looking for a yes. You're looking for evidence strong enough that abandoning the idea would feel irrational.
Why most "validation" fails before it starts
The failure mode is almost never laziness. It's that founders validate the wrong thing with the wrong people.
There are two questions bundled together and people answer only the easy one:
Problem validation vs solution validation
Problem validation asks: does this pain exist, is it frequent, and is someone — anyone — already paying to reduce it? Solution validation asks a different question entirely: given that the pain is real, does your specific answer beat the alternatives, including "do nothing"?
I killed a project in 2023 at the problem stage. A tool for tracking freelance invoices across multiple currencies. Interviews: 22. People complained about it constantly. But when I asked how they handled it today, every single one of them used a spreadsheet plus their accountant. Nobody had ever paid for a fix. Frequency was real; willingness to pay was not. That's a "no" at step one, and it cost me nine days instead of nine months.
Most articles skip this distinction. It's the single most common reason validation produces a false positive.
The compliment trap
Friends, family, and Twitter are terrible samples. They optimize for your feelings, not accuracy. A stranger who's mildly annoyed by your pitch is worth ten acquaintances who say "cool idea."
There's a known bias here worth naming — people consistently overestimate how likely they'd be to buy something hypothetical, which is why "would you buy this?" is close to a useless question. Ask about behavior instead: what did you do last time this problem came up? How much did it cost you? What did you try first?
The validation sequence I actually run
Order matters. Each step is cheap and filters out a category of bad idea before you spend real money on the next one.
Step 1 — problem interviews (1–2 weeks)
Target 20–30 conversations per customer segment. If you have two segments, say B2B teams and individual freelancers, those are two separate counts — don't average them.
Questions I use, roughly in order:
- "Walk me through the last time this happened. What did you do?"
- "What did that cost you — money, hours, or both?"
- "What have you already tried to fix it?"
- "Who else is involved in this decision?"
- "If this were solved tomorrow, what changes for you?"
Notice none of these mention my product. That's deliberate. The moment you describe your solution, you've contaminated the sample.
Kill signal: fewer than 5 of 20 people describe the problem unprompted, or describe it in the past tense with no workaround. If nobody has a hack, it isn't painful enough.
Step 2 — map the alternatives (2–3 days)
Every real problem already has a solution. It's just not yours. List them: competitors, spreadsheets, a part-time contractor, an intern, doing nothing. Then figure out the switching cost.
If the incumbent is "nothing" and the cost of that nothing is low, you're likely building a vitamin, not a painkiller. Vitamins can work, but they need distribution and habit design, which is a much harder game. Worth knowing which one you're in before you commit.
Step 3 — demand test with a landing page (1 week, ~€150)
Put up a single page describing the outcome, not the technology. Add one primary action: a pre-order, a deposit, a waitlist with a real commitment step, or a "book a call" button.
Conversions differ wildly by audience, so I won't pretend there's a universal benchmark. What I track is the relative number: how does this page perform against a page for a variant of the same idea? If two headlines built on the same traffic differ by more than 2x in signup rate, you've learned something about positioning. If both flatline, you've learned something about demand.
One caveat from my own mistakes: waitlist emails are weak evidence. I once collected 900 addresses for a tool and converted 11 into paying users. A pre-order with a refundable €20 deposit is a hundred times more informative than 900 emails.
Step 4 — deliver the outcome manually (2–4 weeks)
This is the concierge MVP, and it's the step most people skip because it's unglamorous. You do the work by hand for 3–5 customers. No automation, no code.
What you learn here is rarely what you expected. In one project, I delivered a weekly report manually for six clients, and discovered that four of them only ever read the first two lines. The product I'd planned to build would have been 80% wasted effort. That insight cost me three weeks of manual work instead of three months of engineering.
Commit signal: at least two customers ask to keep going after the manual period, and at least one asks to pay for it. Not "let me know when it's ready." Asks to pay now.
B2B vs B2C: the signals are not the same
The biggest mistake I see B2B founders make is treating signups as traction. In a company, the person who feels the pain is often not the person who signs the cheque.
| Signal | B2B | B2C |
|---|---|---|
| Who you interview | Both the user and the budget holder | The end user directly |
| Strongest early evidence | Signed pilot agreement or a paid discovery engagement | Pre-order, deposit, or repeat usage of a manual version |
| Typical cycle length | Weeks to months; procurement alone can eat six weeks | Minutes to days; impulse decisions dominate |
| Common false signal | "Send me a proposal" with no follow-up | Free-trial signup with no activation |
| Cheapest useful test | Five paid discovery calls at a nominal fee | Landing page with a refundable deposit |
Charging even a token amount for a discovery call is one of the highest-leverage moves in B2B validation. It filters out the people who are just being polite. I've watched a €200 invoice turn a "definitely interested" list of nine companies into two that actually showed up.
How many interviews is enough?
There's no magic number, but there is a point of diminishing returns. I've found that in a reasonably tight segment, themes start repeating around interview 10–12. By 20, you're mostly hearing the same sentences in a different order.
So: run 20–30 if you can, stop at 12 if the pattern is unmistakable, and go past 30 only if you're still hearing new objections. Objections are the useful material. Praise is noise.
What about AI tools that rate your startup idea?
They're useful for one thing: finding competitors and adjacent products you missed. That's genuine value.
They are not useful for demand. A model can't tell you whether a procurement manager at a mid-sized logistics firm will sign off on a €4k annual contract, because that answer doesn't exist in any training data — it exists in that manager's calendar and budget. Treat these tools as a research assistant, not a verdict. I've seen a tool rate as "high potential" an idea that three real interviews killed in under a week.
When to walk away, and how to make that decision cheap
Set the kill criteria before you start. Write them down. Doing it after the interviews is how you talk yourself into a bad idea.
- Fewer than 5 of 20 interviewees describe the problem unprompted.
- Nobody in the segment currently spends money or meaningful time on a workaround.
- After two manual deliveries, no customer asks to continue or pay.
- The only positive feedback comes from people who know you personally.
- You find yourself redefining the target customer every time the data disagrees.
That last one is the tell. I've done it. When you start saying "well, it's really for agencies, not freelancers" after the freelancer interviews failed, you're not pivoting. You're bargaining.
Budget for the whole validation phase at 4–8 weeks and a few hundred euros. If it's costing more than that, you're probably building, not validating.
The question that actually matters
At the end of all this, the bar isn't "did people say yes." It's whether the evidence is strong enough that stopping would feel like a mistake. Pre-orders, signed pilots, repeated manual usage, people chasing you — those are the shapes that qualify.
And the dog café person? They came back two weeks later with a different idea and eleven pre-orders from a Facebook group. Same founder, same enthusiasm, one extra step of homework. The difference wasn't the idea. It was the order of operations.
