A founder joined a call with us last quarter carrying validation. He had a Notion doc full of it: forty people who said the idea was great, a survey where most respondents picked "very interested," two friends in the industry who told him they would definitely use it. He wanted a build quote. We talked him into spending two weeks on real tests first, and the tests killed the idea in nine days. He was annoyed for about a week, then relieved. The build he almost commissioned started at around $25,000.
That doc is what most founders bring when they say they have validated. Almost none of it survives contact with a stranger's wallet. Here is how we tell the difference, and how we test ideas before we let anyone pay us to build them.
What counts as evidence
Validation evidence has one property: someone gave up something to produce it. Money, time, a signature, their reputation with a boss. A compliment costs the giver nothing and predicts nothing. A pre-order or a signed letter of intent costs something, and that cost is what makes the signal worth reading. The founder's Notion doc had forty entries in it, and by this standard not one of them counted.
This is the entire method. Everything below is a way of making a stranger pay a small price so you can watch whether they do.
The four signals we trust
Pre-sales and letters of intent
The strongest signal, and the one founders avoid because it is scary: ask people to pay before the product exists. For B2B, the softer version is a letter of intent, one page saying "if you build roughly this, at roughly this price, we intend to buy." It is non-binding and still filters out almost everyone who was just being polite, because signing something means explaining it to a manager.
We have seen founders resist this for weeks and then close two pre-sales in the first five calls. We have also seen the opposite: thirty warm conversations that produced zero signatures, which is the answer, delivered cheap. Both outcomes are validation working as intended.
Waitlist conversion, measured properly
A waitlist is a real signal only under conditions most founders skip. The page has to state a price, or at least a price band, because a signup for a free thing tells you nothing about a paid thing. The traffic has to be cold: people from a relevant community, a search ad, a post in a forum where your buyers actually complain. And you count conversion from visitor to signup, not the raw signup total, because 400 signups from 40,000 impressions, to take an illustrative planning example, is a weak result wearing a big number.
As a rough working bar from the landing pages we have run with clients: cold-traffic conversion under one or two percent means the message or the market is off, and a healthy B2B page with a stated price tends to land somewhere in the mid single digits. Treat these as orientation, not law. A founder's own list and launch-day spike will always look better than the durable truth.
Strangers accepting a manual concierge version
Before there is software, there is you doing the job by hand. If the idea is a tool that matches, summarizes, schedules, or automates something, offer to do that thing manually for a handful of real customers, for money or at least for a firm weekly commitment. This is the concierge test, and it is the most underrated signal on this list because it validates the outcome instead of the interface.
Two things can happen. Strangers pay for the manual version and keep using it, which means the value is real and the software is a margin decision. Or they try it once and drift away, which means the problem was not painful enough, and no interface would have fixed that. Either way you learned it for the cost of your own hours. Paul Graham made the broader case for this in Do Things That Don't Scale, and it has aged well.
Competitor churn complaints
Your future customers are already describing your product in public, in the one-star and two-star reviews of whoever serves them badly today. Read the G2, Capterra, Trustpilot, App Store, and Reddit complaints for the two or three closest competitors and code them: what made people leave, what they said was missing, what they switched to, how long they tolerated the gap before leaving.
The signal is specific. Complaints about a missing capability you plan to build, repeated across months and reviewers, show a problem worth testing. They do not prove that buyers will pay for your product or that your solution is the missing capability; that is what the other three signals are for. Complaints about price or support quality mean the market wants the same product cheaper or nicer, which is a much harder wedge. We do this review mining inside discovery, and it regularly changes what the MVP's core flow should be.
Signals that feel like validation and are not
Compliments are the worst offender because they feel like data. "That's a great idea" is a social reflex, not a purchase intent. Survey interest is nearly as bad: a checkbox labeled "very interested" commits nobody to anything, and an opt-in survey sample is not the same thing as cold buyer demand. And the friends-and-family round of opinions is actively misleading, because people who like you will protect you from the truth.
If this sounds harsh, read The Mom Test before your next ten conversations. The whole book is one technique: stop asking people whether they like your idea, and start asking about the last time they had the problem, what they did about it, and what it cost them. Past behavior is evidence. Opinions about your idea are weather.
One trade-off we will admit: this standard is easier to meet in B2B than in consumer. A consumer app with a long free tier genuinely cannot pre-sell its way to validation the same way, and for those we lean harder on the concierge test and prototype behavior. The standard bends. It does not disappear.
How we run discovery before an MVP sprint
When a founder comes to us through our page for entrepreneurs with an idea, the first engagement is usually not a build at all. It is a short discovery, typically two weeks, run by the same German-led project leadership that would later run the sprint.
The shape of it: we interview the founder and then a dozen or so people from the target segment, using Mom Test rules, so we hear about past behavior instead of collecting compliments. We mine competitor reviews for the churn complaints described above. We put a price-bearing landing page or a clickable prototype in front of cold traffic, and when the idea suits it, we help the founder sell a concierge version to two or three real customers. The prototype step is deliberately cheap: our UI/UX design team builds something clickable in days, because the question is whether anyone leans forward, not whether the pixels are final.
Discovery ends with a written verdict. Go, with a scoped core flow and the evidence attached. Narrow, when one segment responds and the rest do not. Or stop, with the reasoning written down so the founder can defend the decision to a co-founder or an investor later. About a third of the ideas that enter our discovery come out as narrow or stop, and we consider that the service working, not failing.
The idea we talked a client out of
One example, anonymized because that was the deal. A founder in a services industry wanted a marketplace connecting small local providers with business customers. He had the survey results and the enthusiastic friends, and he had budget for a full build.
In discovery, two things surfaced. The competitor churn complaints were almost entirely about price and no-shows, not about a missing platform, which meant the wedge he imagined was not the pain people actually felt. And when we helped him offer the matching service manually, by phone and spreadsheet, providers were happy to receive leads but would not commit to anything that cost them time or money, and the business customers mostly wanted one recommendation, fast, not a marketplace to browse.
We wrote the stop verdict. He did not build the marketplace. What he did instead, with a fraction of the budget, was a narrow booking tool for the provider side, where the pain had shown up in the interviews. That version had paying users within weeks of launch. The expensive idea died in a two-week discovery for a small fraction of what the first sprint would have cost, and the cheap idea that survived was one he had not walked in with.
When the signals say go
Validation done properly ends in a build decision, and this is where founders overcorrect. Evidence does not mean build everything. It means you now know which single flow strangers will pay for, and that flow is the MVP, scoped tight enough to ship in weeks. Our MVP sprint package exists for exactly this moment: fixed scope, about four weeks, a defined handover. If you want the money side first, we published honest ranges in what an MVP costs in 2026.
And if your evidence is still a Notion doc of compliments, that is fixable in a couple of weeks. Talk to us before you commission a build you will have to validate afterward.
Frequently asked questions
How many customer interviews do I need to validate an app idea?
Fewer than you think, if you ask the right questions. In our discovery work, patterns usually stabilize after 12 to 20 conversations with people who actually have the problem, and you can often hear the answer by interview eight. Ten honest conversations beat two hundred survey responses, because a conversation can follow a surprising answer somewhere useful.
Can I validate an app idea without building anything?
Yes, and you should. A landing page with a waitlist, a clickable prototype, direct pre-sales conversations, and a manual concierge version of the service all produce real demand signals without a line of production code. Production use is the point where retention and in-product behavior can be tested directly; everything before that validates demand and willingness to act, which is what these tests are for.
How long should validation take before I start an MVP?
Two to four weeks of focused effort is enough for most B2B and prosumer ideas. If you have run real tests for a month and still cannot get anyone to commit money, time, or a signature, more weeks of the same tests will not fix it. Either change the audience, change the problem, or stop.
What if my validation results are mixed?
Mixed results usually mean the segment is wrong, not the idea. When one audience commits and another politely declines, narrow to the audience that commits and validate again at that narrower scope. A strong signal from a small group beats a weak signal from everyone.