What Should You Validate Before Building Your MVP?
Most founders skip validation and burn $20K building the wrong thing. Here are the 4 things you must validate before writing a single line of code.
"Everyone I talked to said they'd use it."
This is the most dangerous sentence in early-stage startups. It sounds like validation. It feels like validation. It is not validation.
When a friend, colleague, or even a stranger says "yeah, I'd totally use that" — they're being polite. They're pattern-matching to your enthusiasm. They're not making a commitment. The gap between "I'd use it" and "I paid for it" or even "I signed up for the waitlist" is where most startup ideas go to die quietly.
Real validation is a demand signal, not a social reaction. Here's what that actually means, and how to get it before you spend anything on development.
Social Validation vs. Demand Signals
Social validation is what happens when you pitch your idea and people respond positively. It feels good. It's also nearly worthless as a data point.
Demand signals are behaviors. Someone gives you their email address unprompted. Someone hands you $50 to be on a list. Someone cancels a current subscription because they expect yours to be better. Someone refers a friend before the product exists. These behaviors indicate that the problem is real and the proposed solution is compelling.
The founders who build the wrong thing aren't stupid — they have genuine enthusiasm and genuine positive feedback. What they lack is evidence of behavior. Talking to people about a problem is research. Getting them to act on a solution is validation.
The distinction matters because behavior is what your business actually runs on. Opinions don't pay invoices.
The 4 Things to Validate Before You Build
Problem: Is it real and painful enough?
The test here is whether people describe the problem without prompting. If you have to explain the problem before asking if they experience it, that's a signal. If you say "do you ever struggle with X?" and they immediately say "oh god, all the time — let me tell you about last Tuesday," you have a real problem.
Painful problems are ones people are already spending time, money, or emotional energy on. They've built workarounds. They use janky spreadsheets. They've hired someone to do it manually. They've tried other tools and been disappointed. These are the indicators that a problem is worth building for.
Ask yourself: Are people already paying to solve this problem, even imperfectly? If yes, the problem is real. If people aren't paying anyone for anything in this space, either the problem isn't painful enough or the market is very early — both of which should make you slow down.
User: Who exactly has this problem?
"Everyone" is not a user. "Small businesses" is not a user. "Busy professionals" is not a user.
Your ICP (ideal customer profile) for v1 needs to be narrow enough that you could describe a specific person. "Freelance graphic designers who work with 3+ clients simultaneously and currently manage invoices in Google Sheets" is a user. You can find that person. You can talk to them. You can put them in front of your product.
The tighter your user definition, the faster you can validate. A broad target means your feedback is noise — you're getting responses from people with different problems, different contexts, and different thresholds for pain. Narrow it down to the person who has the problem most acutely and who can make a decision to buy quickly.
If you're struggling to describe a specific person, you're not ready to build. You're still in discovery.
Willingness to Pay: Have they paid for something adjacent? Will they pay now?
The most reliable validation signal is money. Not a promise of money. Not an expression of interest. Actual money — or a commitment of money that has real consequences if they back out.
Two questions to answer here. First: have they already paid for something in this problem space? If your target user is paying $200/month for a tool that partially solves their problem, you know they've decided the problem is worth spending on. That's your baseline. If they've never paid anyone for anything related to this problem, you need to understand why before you price your solution.
Second: will they pay now, before you've built anything? This is the best test. A pre-sale, a deposit, or a paid pilot locks in real commitment. "I'd pay for that when it's ready" is an opinion. "$500 down payment to get on the founding-user list" is a demand signal. Even $50 tells you something. People do not give money to things they don't actually want.
If 10 people in your ICP won't commit even a token amount before you build, that tells you something important. It doesn't mean the idea is dead — but it means you haven't yet made the value clear enough to overcome inertia.
Distribution: How will you reach your first 100 users?
This is the most overlooked validation question, and it's just as important as the others.
If you can't answer "how will I get my first 100 users?" with a concrete, specific answer — not "social media" or "word of mouth" but "I'm a moderator in a Slack community of 3,000 freelance designers and I'll post there" or "I have 200 leads from my previous job in this industry" — then the product question is premature.
Distribution is not a post-launch problem. It's a pre-build validation question. A product no one can find is not a product. Before you invest in building, validate that you have a path to your first users that doesn't require going viral or being on the front page of ProductHunt.
Ask: "If this launched tomorrow, what would I do on day one to get 10 users?" If you can't answer that with confidence, keep working on distribution before you work on the product.
Fast Validation Methods That Actually Work
You don't need to build anything to validate. Here are the methods that consistently generate real signal.
Landing Page With a Waitlist (But Measure Conversion, Not Just Signups)
A simple one-page site describing the problem, the solution, and a waitlist signup is the fastest way to test whether strangers care. The metric is not raw signups — it's conversion rate from visitor to signup.
If you drive 500 targeted visitors to your page and 8% sign up, that's a meaningful signal. If you drive 10,000 untargeted visitors and 0.3% sign up, that's noise. Traffic source matters as much as signup count.
If 10 people won't give you their email address, 10,000 won't pay you money. A low-converting waitlist page isn't a traffic problem — it's a messaging or value proposition problem. Fix the message before you buy more traffic.
Concierge MVP: Do It Manually First
Before you automate anything, do the job manually for 3–5 real users. If you're building a tool that matches freelancers with clients, match them yourself — by hand, using email, Google Docs, whatever you have. If you're building a tool that generates reports, generate the reports yourself using spreadsheets.
This does two things. First, it proves the value proposition works before you build the technology. Second, it forces you to understand the actual job well enough to automate it later. Founders who skip the manual phase often build the wrong automation.
You're looking for users who come back, refer others, and eventually ask "why isn't this faster?" That's your signal to build.
Pre-Sell Before You Build
Send a Stripe payment link. Send a PayPal invoice. Take a deposit over email. The mechanics are less important than the act of asking someone to pay for something that doesn't exist yet.
This is uncomfortable. That discomfort is the point. Most founders avoid pre-selling because rejection is very real when money is on the table. But that's exactly why it works as a validation signal — when someone pays, you know they mean it.
A target of 3–5 paying pre-customers before you commit to building is a reasonable bar. If you can't get 3 people from your target market to put money down, reconsider the scope, the positioning, or whether you've correctly identified the customer.
The Fake Door Test
Create a button, a page, or a call-to-action for a feature that doesn't exist yet. When someone clicks it, you capture their interest and explain that the feature is coming soon. You're measuring demand for something before building it.
This works especially well when you have an existing audience or traffic source. It lets you rank-order features by actual user interest rather than your own assumptions.
A waitlist of 500 people who found you on ProductHunt is not the same as 20 people from your ICP who said they'd cancel their current tool for yours. Volume of generic interest is not a substitute for depth of commitment from the right people. Ten paying pre-customers from your exact target market outweighs a 1,000-person waitlist of curious observers every time.
When Have You Validated Enough to Start Building?
There's no universally correct threshold, but here's a practical set of signals that indicate you're ready:
At least one person has paid or made a firm commitment. This doesn't have to be a large amount. Even $100 or a signed letter of intent from a pilot customer is meaningful. Money or firm commitment changes the nature of the feedback you get and the relationship you have with that customer.
You've had real conversations with 10 or more people from your target market. Not friends. Not family. Not people who know you and want to be supportive. Strangers, or near-strangers, who have the problem you're solving. You should be able to describe patterns in what they told you — common language they use, common workarounds they've tried, common frustrations with existing tools.
You can describe the core flow in two sentences. "A freelancer signs up, connects their calendar, and receives a weekly report showing their utilization rate and projected income." If it takes you a paragraph to describe what your product does for a user, the scope isn't clear enough yet. The two-sentence test forces the clarity that good v1 specs require.
When you have all three of these, you're not guessing anymore. You're building from evidence. The product you build will be better, the scope will be tighter, and the probability of building something people actually use goes up significantly.
If you're missing one or more, figure out which one is hardest to get — and work on that, not the product.
Not sure if you've validated enough to start building? In a single consultation call, we can help you stress-test your assumptions and figure out the right first step — whether that's building or validating more. Book a free call →
Startup & Product Advisors
The Joistic team builds AI-powered design tools that help founders and developers visualize app ideas before writing a single line of code.
