BuildInSeven
← All articles

When to Stop Validating and Start Building

6 min read

Clear signals that tell you when you have enough validation to commit to building your app—and the signs that say you need one more round of evidence first.

You have enough validation to start building when you have spoken to at least ten to fifteen target users, identified a pattern of pain they cannot solve with existing tools, collected a concrete commitment signal from at least five of them (a deposit, a signed letter of intent, or a paid pilot), and confirmed you can reach more users like them. If all four conditions are true, further validation is delay, not diligence.

Why This Decision Is Hard

Validation loops are comfortable. Every conversation, survey, or landing page test feels productive without carrying the financial and emotional weight of a real build. The result is founders who run six months of research on an idea that could have been tested in market within weeks.

The opposite mistake is just as common: founders who mistake early enthusiasm for validated demand and start building after three encouraging calls, only to discover those three people were polite, not committed.

The question is not whether you have evidence. The question is whether the evidence you have is the kind that predicts a paying customer.

The Four Signals That Say You Are Ready

1. You Have a Clear, Repeating Problem

When you describe the problem your app solves and people interrupt you to say "yes, that happens to me every week", you have found something real. When you have to explain why the problem matters, you have not.

Aim for ten to fifteen conversations with people who fit your target profile. By conversation twelve, you should be hearing the same frustrations in nearly the same words. If every conversation reveals a completely different version of the problem, you need more discovery, not a build.

One useful signal: after the conversation, ask the person to rate the problem on a scale of one to ten. Anything below a seven means it is not painful enough to drive purchasing behavior. A cluster of eights and nines means you are onto something.

2. Existing Solutions Are Inadequate and People Know It

Asking someone whether they currently solve this problem tells you more than asking whether they want your solution. If they describe a workaround (a spreadsheet, a manual process, a combination of three tools that half-works), that workaround is your real competitor.

The gap between "I have a workaround" and "my workaround costs me time and money I can measure" is where product demand lives. If users can quantify the cost of the problem, they can justify paying to fix it.

3. You Have a Commitment Signal, Not Just Interest

Verbal enthusiasm is cheap. Commitment signals cost the person something, which is what makes them predictive.

Signal TypeWhat It Looks LikeStrength
Deposit or pre-paymentUser pays a small amount to reserve accessVery strong
Signed letter of intentUser commits in writing to try the productStrong
Paid pilotUser pays for a manual version of the outcomeStrong
Agreed onboarding dateUser schedules time to start using the productModerate
Referral to a colleagueUser introduces you to another potential userModerate
Joining a waitlistUser submits their emailWeak
Saying "I would use this"Verbal onlyVery weak

Five users at the "strong" level is more meaningful than fifty waitlist signups. If you have run a fake door test and seen genuine click-through from people who then expressed frustration at finding no product, that is a strong signal. People who get annoyed that the product does not exist yet are telling you they wanted it.

4. You Know Where to Find the Next Hundred Users

One cohort of early interviews can be explained away as selection bias. If you already know specific communities, publications, job titles, or channels where people like your interviewees gather, you have de-risked acquisition before you write a line of code.

If you cannot answer "where would I find fifty more people like the ones who told me this was painful?", that is a validation gap worth closing before you build. The guide to finding early users before you build covers the practical channels in detail.

Signs You Should Keep Validating

Not every hesitation is procrastination. Some founders genuinely need another round of evidence. These are the patterns that warrant it:

The problem keeps shifting. Each interview reveals a different angle of the problem, and you keep expanding scope to accommodate it. Build the smallest version that solves one specific problem for one specific user type. If you cannot define that version yet, your problem is not crisp enough.

Nobody has committed. You have had positive conversations but no deposits, no letters of intent, no paid pilots. Positive conversations without commitment signals mean you have confirmed the problem exists, not that people will pay to solve it.

You are building for yourself. If the primary evidence is your own frustration with the problem, you need external confirmation. Your own pain is a starting point for ideation, not a substitute for market evidence.

Your target user is vague. "Small businesses" is not a user. "Operations managers at logistics companies with five to twenty-five employees" is a user. If your interviews have been with a wide mix of people and you cannot describe a clear pattern across them, narrow the profile and run another round.

How to Run One More Focused Round Without Losing Momentum

If the signals above suggest you need more evidence, a targeted two-week sprint is usually sufficient. Set a specific question you are trying to answer, not a general "let me talk to more users" exercise.

For example: "I need to confirm that operations managers, specifically, experience this problem, not just founders." Then book eight conversations in that segment, set a decision date, and treat that date as a genuine deadline.

A focused validation round with a fixed end date is productive. An open-ended validation phase with no decision criteria is avoidance.

The broader framework for structuring validation from the beginning lives in How to Validate a Software Idea Before You Build. If you are early in the process, start there. This article assumes you have already done the foundational work and are deciding whether the evidence is sufficient.

The Cost of Over-Validating

Every week spent validating when you already have sufficient evidence is a week a competitor could be shipping. More concretely, it is a week of not learning from real usage data, which is the richest source of product insight available.

Pre-launch user interviews tell you what people say they will do. Post-launch behavior tells you what they actually do. The gap between those two things is always instructive, and you cannot close that gap without building.

When you have commitment signals from five or more users, a clear problem pattern, and a defined acquisition channel, the risk of building is lower than the risk of waiting.

A Simple Decision Framework

Before you commission a build, answer these five questions:

  1. Have you spoken to at least ten people who fit your target profile?
  2. Do at least seven of them describe the same core problem in similar terms?
  3. Have at least five provided a commitment signal stronger than a waitlist signup?
  4. Can you describe, in one sentence, the single most important problem your first version must solve?
  5. Do you know at least three specific channels where you can find your next hundred users?

If you answered yes to all five, you have enough to build. If you answered no to two or more, identify which gaps remain and close them with a time-boxed sprint before you spend development budget.

Frequently asked questions

How many user interviews do I need before I start building?
Ten to fifteen interviews with people who match your target profile is usually enough to identify a reliable pattern. The number matters less than the consistency: if you are hearing the same problem described in similar language by the majority of people you speak with, you have found something real.
Is a waitlist enough to justify building?
A waitlist shows interest, not demand. Email signups are low-commitment actions that do not predict purchasing behavior. Treat a waitlist as one data point among several, not as validation on its own. A smaller number of users who have paid a deposit or signed a letter of intent is stronger evidence than a large waitlist.
What if I keep discovering new problems during validation?
That usually means your target user definition is too broad. If each interview reveals a different version of the problem, narrow your profile until you find a segment where the problem is consistent. Build for that segment first.
Can I validate and build at the same time?
For most non-technical founders, running both in parallel dilutes attention and produces worse outcomes on both fronts. The exception is a paid pilot: delivering a manual version of the outcome while scoping the software build is a legitimate parallel track because the pilot itself is validation.
What does a commitment signal look like in practice?
Common forms include a small deposit to reserve access, a signed letter of intent to use the product when it launches, payment for a manual version of the service, or a scheduled onboarding date. The defining characteristic is that the user has done something that costs them time, money, or social capital—not just expressed enthusiasm in a conversation.