Startup Validation Checklist: Before You Build

A founder spends four months building a SaaS dashboard for a niche industry they used to work in. The product is clean. The features match the spec. The launch lands. The dashboard is ignored. Not because it's bad. Because the people they imagined using it never had the problem they thought they did. The founder's mistake wasn't execution. It was skipping the part where they checked.

I've watched versions of this play out with people much smarter than me. Builders who knew the technology cold, had real domain experience, and believed they were solving a problem they had personally felt. The discipline of testing it before investing in it was just missing.

That's what this checklist is for. A structured way to find out before you've spent three months finding out the expensive way.

Validation is about reducing uncertainty. The goal isn't to prove your idea is right. The goal is to discover where it might be wrong.

Key takeaways

• The bottleneck for most first-time founders isn't creativity — it's discipline. Almost every founder has more ideas than they can build in a lifetime. The hard part is having the patience to check whether the current one deserves the next three months.
• Validation is a sequence of four stages: problem, customer, business, execution. Each stage gates the next. There's no point testing whether you can execute if the problem isn't real.
• Twenty-one concrete checks across the four stages. Each item has a "why it matters," a "how to test," and the "common mistake" that catches most founders off guard.
• The red flags are signal, not verdict. Can't describe your first customer, no one has agreed to pay, you don't know where your users gather — each one is information that points to the next experiment.
• A two-to-four-week active validation cycle is enough for most solo founders. Less than a week usually means you didn't run enough experiments; more than four usually means you're procrastinating instead of building.

Why this matters

A checklist is only useful if it gets used. This one is structured so that a solo founder can sit down on a Sunday afternoon with a notebook, run through the 21 items, and end the session with a clear picture of which assumption is the weakest. The structure is deliberate: every item has a "why it matters," a "how to test," and the "common mistake" that catches most founders off guard. The point is not to memorize the list. The point is to know which questions to ask, and which signals to watch for, when you sit down to test your idea.

The items are sequenced so that the cheap tests come first and the expensive tests come last. The first five items cost nothing and take a weekend. The middle ten require outreach and may take a week or two. The last six require a prototype, which is the most expensive thing on the list — and the reason it comes last. Skipping ahead to the prototype is the most common mistake this checklist is designed to prevent.

Yibud's perspective

Yibud's report maps directly to the four stages in this checklist. Stage 1 (problem validation) maps to the market-demand score. Stage 2 (customer validation) maps to the distribution score. Stage 3 (business validation) maps to the monetization and competition scores. Stage 4 (execution validation) maps to the build-difficulty and founder-fit scores. The platform's riskiest-assumption output is, in effect, the unchecked item on this checklist.

The checklist is the framework. The platform is the second opinion. Both are useful. The framework is what the founder runs themselves. The second opinion is what surfaces the item the founder is most likely to skip.

If you'd like the four stages applied to your specific idea in five minutes, Yibud's startup validation analysis returns the riskiest unchecked item as a starting point.

Why Most Founders Don't Need More Ideas

The bottleneck for most first-time founders isn't creativity. It's discipline.

Almost every founder I've talked to has more ideas than they can build in a lifetime. The hard part isn't coming up with the next thing. The hard part is having the patience to check whether the current thing deserves the next three months of your life.

Once you have an idea, your brain starts treating it as a thing that exists. Each imagined future makes the idea feel more obviously correct, which makes testing it feel like wasted time.

The founders who ship useful things treat their own enthusiasm as a hypothesis. You don't need more ideas. You need a repeatable process for testing the ones you have.

The Four Validation Stages

Validation isn't a single event. It's a sequence of stages, each answering a different question. Skipping a stage is how founders end up building things nobody wants.

1. Problem Validation — Does the problem exist, and is it painful enough to solve?
2. Customer Validation — Can you find, reach, and talk to the people who have this problem?
3. Business Validation — Will those people pay enough, in a way that makes a business, for a solution?
4. Execution Validation — Can you, specifically, build and ship this solution given your real constraints?

Each stage gates the next. There's no point testing whether you can execute if the problem isn't real. There's no point testing whether people will pay if you can't find them.

The Complete Startup Validation Checklist

Every item below is a question, a reason it matters, a way to test it, the mistake most founders make, and a real-world example. Read it once, then come back with a notebook and your specific idea in mind.

Stage 1: Problem Validation

1. Can you describe the problem in one sentence without mentioning your solution?

Why it matters: If you can't describe the problem clearly, you don't understand it well enough to test it. Most founders describe their product when asked about the problem. That's a tell.

How to test: Write the problem statement. Show it to five people in your target audience. If they can repeat it back, you have a clear problem. If they ask "wait, what's the product?" you've drifted into solution-thinking.

Common mistake: Describing the problem in terms of features. "The problem is that there's no tool that does X" is a feature gap, not a problem.

2. Do people experience this problem frequently, or only occasionally?

Why it matters: Frequency is the difference between a real market and a curiosity. A freelancer who invoices once a month has a problem. A freelancer who invoices 50 clients a week has a different problem. The second one is willing to switch tools. The first one probably isn't.

How to test: Ask: "How often does this come up? Walk me through the last time." Listen for words like "every day," "every week," "constantly." If you hear "sometimes," "occasionally," or "when I remember," the frequency is too low.

Common mistake: Conflating "this would be nice" with "this is urgent." Nice-to-haves don't get paid for.

3. Are people actively trying to solve this problem today, even badly?

Why it matters: A problem people are solving with spreadsheets, manual work, or workarounds is a problem they care about. A problem nobody is solving is often not a problem at all.

How to test: Ask: "What do you do today when this comes up?" If the answer is "I just live with it," the problem isn't painful enough. If the answer is "I use three different tools and a spreadsheet," there's a real need.

Common mistake: Mistaking "nobody is solving this" for "there's an open opportunity." Often, nobody is solving it because it's not worth solving.

4. Have you talked to at least five people who experience this problem?

Why it matters: Your opinion of the problem doesn't matter. Your friends' opinions don't matter. The opinions of people who actually have the problem are the only data that count.

How to test: Find five people in your target audience. Not friends, not family. People who fit the customer profile. Have a 20-minute conversation. Take notes.

Common mistake: Counting conversations that didn't happen. "I would talk to people" is not the same as having talked to them.

5. Can you describe the specific moment when the problem is most painful?

Why it matters: "Sometimes I wish I had a better way to track my tasks" is vague. "Every Monday morning I spend 90 minutes reformatting the report my boss wants" is specific. The more specific the moment, the more you understand the customer.

How to test: Ask: "Walk me through the last time this happened. What time of day? Who else was involved?" Listen for vivid detail. Vivid detail means real memory means real problem.

Common mistake: Accepting the polished answer. People describe problems abstractly when asked directly. The specific moment is what reveals whether the problem is real.

Stage 2: Customer Validation

6. Can you describe your first 10 customers by name, role, and where they spend time online?

Why it matters: "Small business owners" is a segment. A segment isn't a customer. If you can't name ten specific people, you don't know who you're building for.

Naming ten real people is harder than it sounds — and it's exactly the work the first-customers guide walks through step by step. Use that guide alongside these checklist items when Stage 2 starts to feel abstract.

How to test: Try to find ten people. Look on LinkedIn, search Reddit, browse Twitter. If you can't find them in 30 minutes, the audience is harder to reach than you think.

Common mistake: Targeting "everyone who has this problem." If your customer is everyone, your customer is no one.

7. Do you know where these people already gather (online or offline)?

Why it matters: Distribution is the assumption technical founders underestimate most. If you don't know where your future customers already spend time, you have no plan to reach them.

How to test: List three specific places (subreddits, Slack groups, conferences, podcasts, newsletters, Discord servers) where your target customer shows up. If you can't list three, you don't know your customer well enough.

Common mistake: Assuming the audience is "on the internet." So is everyone. You need to know where, specifically, they congregate around your problem.

8. Have you successfully started a conversation with at least three of them?

Why it matters: Reaching people is one skill. Starting a conversation with them is another. If you can't get a stranger in your target market to spend 10 minutes with you, acquisition cost will be brutal.

How to test: Send 10 cold DMs, emails, or in-person introductions. See how many respond. If under 30%, your outreach needs work or your positioning is off.

Common mistake: Confusing "I have access to a large audience" with "I can reach my specific customer." A Twitter following of 10,000 doesn't help if your customer is mechanical engineers.

9. Have you watched someone actually try to solve the problem in real time?

Why it matters: Talking to people about their problems is useful. Watching them try to solve it is more useful. The gap between what people say and what they do is where most failed startups come from.

How to test: Ask an interviewee to walk you through their last attempt at solving the problem. Screen-share if possible. Take notes. Twenty minutes of observation beats five conversations of asking.

Common mistake: Trusting what people say they'll do. People lie to themselves about their own behavior. Watching is more honest.

10. Can you explain, in one paragraph, why your target customer would switch from their current solution to yours?

Why it matters: "It's better" is not a switching reason. Switching has costs. If you can't articulate the specific trigger that would make someone change tools, switching cost will kill you.

How to test: Ask your interviewees: "What would it take for you to switch from [current solution] to something new?" If the answer is "I don't know" or "nothing really," your value proposition isn't strong enough.

Common mistake: Assuming "10x better" is a real thing. Most products are 20% better in a specific scenario, and the founder needs to know what that scenario is.

Stage 3: Business Validation

11. Have you asked at least three people to pay, pre-order, or commit in writing?

Why it matters: Verbal interest is the weakest signal in business. A credit card, a pre-order, a signed letter of intent — these are signals that survive the gap between "I would buy this" and "I'm buying this." For the full mechanics of running a real pricing test — including how to recognize polite interest and design a seven-day payment experiment — see the willingness-to-pay article.

How to test: Build a simple landing page with a pre-order. Drive 200 qualified visitors. If zero convert, you have signal worth investigating. If 5-10% convert, you have something worth building.

Common mistake: Counting "I'd definitely buy this" as a commitment. People say that all the time and then never do.

12. Do you know the price you can charge, with evidence?

Why it matters: Most founders pick a price out of thin air, often too low because they're afraid to ask for more. Pricing is a hypothesis. Test it.

How to test: Survey your target audience. Ask: "What would you expect to pay for [this product]?" Then test three price points with real offers and see which converts.

Common mistake: Discounting before testing. The instinct to be cheap comes from fear.

13. Have you calculated the unit economics, even roughly?

Why it matters: A business that loses money on every customer is a charity. You need ballpark numbers: how much it costs to acquire a customer, how much they pay, how long they stay. If the math doesn't work on paper, it won't work in production.

How to test: Estimate CAC from your distribution experiments. Estimate LTV from comparable products in the market. If LTV is less than 3x CAC, the unit economics are bad. If it's more than 3x CAC, you have a business.

Common mistake: Ignoring the math because "we'll figure it out later." You won't. The math gets worse as you grow, not better.

14. Have you identified a competitor and explained why you win?

Why it matters: "No competition" usually means "no market." "We have competition" is a better starting point because it proves the market exists. Your job is to explain the wedge.

How to test: List three direct and three indirect competitors. For each, write one sentence about why someone would still choose you. If you can't fill in those sentences, your positioning is too vague.

Common mistake: Calling yourself "the X but better" without evidence that "better" matters. Better for whom? In what scenario?

15. Have you talked to someone who chose a competitor and asked them why?

Why it matters: Customers who chose someone else have the most honest feedback. They had the same problem, they picked a solution, and their reasoning tells you exactly what your wedge has to be.

How to test: Find 3-5 users of competing products. Ask: "Why did you pick this one? What would make you switch?" Their answers will reshape your product roadmap.

Common mistake: Ignoring competitors because "they're doing it wrong." Customers don't care who's right. They care what works.

Stage 4: Execution Validation

16. Have you built a working prototype you can show?

Why it matters: Until you've built something, even a bad version, you don't know if you can build it. Talking about building is not building.

How to test: Spend two weeks building the smallest version that solves the core problem. If you can't build it in two weeks, the scope is too big.

Common mistake: Spending three months on the prototype before showing it to anyone. A bad prototype tested with real users is more valuable than a perfect one tested with no one.

17. Have you shown the prototype to at least 5 target users and watched them use it?

Why it matters: Watching someone use your product is brutal and necessary. They get stuck in places you didn't predict, ask for features that surprise you, and use it in ways you didn't design for. All of that is data.

How to test: Schedule 30-minute sessions. Don't explain the product. Hand it to them. Watch. Take notes. Ask "what were you expecting to happen here?" every time they get stuck.

Common mistake: Pitching the product instead of letting them use it. Pitching is theater. Watching is research.

18. Can you describe the technical approach in plain language?

Why it matters: If you can't explain how you'd build it to a smart non-technical person, you don't understand the approach. Hand-waving hides real complexity.

How to test: Write a one-page description of the technical approach. Show it to a peer. If they have clarifying questions, you have work to do.

Common mistake: Treating "I'll use AI for that" as a complete answer. AI is a tool, not a solution. You still need to know what data it needs and what the failure modes are.

19. Have you identified the riskiest part of the build and tested it?

Why it matters: Every product has a technically risky component — the part you don't know if you can build. Find it. Test it. If you can build the risky part in a week, the rest is execution. If you can't, the product might be infeasible.

How to test: List every part of the product. Mark the unknowns. Spend a week on the most unknown one. If you make progress, you can build. If you don't, the product needs a different approach.

Common mistake: Building the easy parts first because they're fun. The risky part is the one that determines whether you ship.

20. Do you have a credible 30-day shipping plan?

Why it matters: Most founders can't honestly say "I'll ship in 30 days." They can say "I'll keep working on it." That's a different commitment. A 30-day plan forces tradeoffs.

How to test: Write the plan: what you'll build, what you'll skip, how you'll get it in front of 10 users. Show it to someone who'll call you out if it's wishful thinking.

Common mistake: Planning a 30-day MVP and then spending month 4 polishing it. Ship the rough version. Get feedback. Iterate.

21. Do you have enough runway (time, money, or energy) to survive the validation phase?

Why it matters: Validation isn't free. It costs time, sometimes money, often energy. If you're about to run out of runway, you'll skip steps. Skipped steps produce bad data.

How to test: Be honest. Do you have 4-6 weeks of dedicated time? $500 for landing page tests and ads? Energy to do customer interviews after your day job? If not, pick a smaller validation scope.

Common mistake: Treating validation as free. It costs something.

Red Flags

If any of the following are true about your idea, slow down. Not necessarily stop. Slow down.

You cannot describe your first customer. If you can't describe a specific person who would buy this, you have a product in search of a customer. That's the most common reason products fail.

Nobody has agreed to pay. If you can't get a single pre-order, deposit, or signed letter of intent, the demand isn't strong enough yet. You don't know if it ever will be.

You don't know where your users spend time. If you can't list three places your target customer already gathers, you have no distribution plan. Distribution is half the business.

Only friends say your idea is good. Friends are biased toward kindness. Strangers in your target market who reach for their wallet are the only signal that matters.

You haven't spoken to a real customer. If you haven't had at least 5 conversations with people who actually have the problem, you're building on assumption.

You keep adding features to the MVP. Every added feature delays the real test. A smaller MVP tested with real users beats a perfect MVP tested with no one.

The problem only matters to you. If you can't find anyone other than yourself for whom this is a top-3 priority, you might be solving a personal problem.

Each of these red flags is information, not a verdict. Most founders will see themselves in at least two. The point is to know where the risk lives, and address it before it kills you.

Real Startup Examples

These are public, well-documented cases. The point is to notice that none of them started with a finished product.

Dropbox. Drew Houston didn't start by building a syncing engine. He recorded a three-minute demo video explaining what the product would do and posted it on Hacker News. The waitlist response was the validation.

Buffer. Joel Gascoigne built a two-page website describing Buffer, including pricing tiers, before writing a line of code. Pre-orders were the company's first revenue.

Airbnb. Brian Chesky and Joe Gebbia didn't start by building a global marketplace. They rented out air mattresses in their own apartment during a conference when hotels were full, photographing listings by hand.

Basecamp. Jason Fried and David Heinemeier Hansson built Basecamp in public. The waitlist grew from the writing, not from the product.

The validation methods were different. The discipline was the same: test before you invest.

Printable Validation Checklist

Save this. Print it. Tape it above your desk. Check items off as you go.

Problem Validation

• Can describe the problem in one sentence
• Problem occurs frequently (not occasionally)
• People are actively trying to solve it today
• Talked to 5+ people who have the problem
• Identified the specific moment the problem is most painful

Customer Validation

• Can name 10 specific potential customers
• Know 3+ places they gather (online or offline)
• Started conversations with 3+ of them
• Watched someone try to solve the problem
• Can explain why they'd switch from their current solution

Business Validation

• Asked 3+ people to pay, pre-order, or commit in writing
• Tested at least one price point with real traffic
• Calculated ballpark unit economics (LTV vs CAC)
• Identified direct and indirect competitors
• Talked to someone who chose a competitor and asked why

Execution Validation

• Built a working prototype
• Showed it to 5+ target users and watched them use it
• Can describe the technical approach in plain language
• Tested the riskiest part of the build
• Have a credible 30-day shipping plan
• Have enough runway to survive the validation phase

When every box is checked, you have evidence. You still won't have certainty. You'll never have certainty. But you'll have less uncertainty than you did before, and you'll know which assumptions are still soft.

Frequently Asked Questions

How long should startup validation take?

For most solo founders, two to four weeks of active validation is enough to test the riskiest assumptions. Less than a week usually means you didn't run enough experiments. More than four weeks usually means you're procrastinating instead of building. The goal is enough evidence to commit, not to eliminate all uncertainty.

Can I validate without building an MVP?

Yes, and you should. The whole point of validation is to learn before you invest in building. Landing pages, pre-orders, manual services, customer interviews, and small experiments can test demand and willingness to pay without writing a line of code. If you can't validate without code, your assumptions about who you're building for are probably too vague. An MVP is a tool for learning, not a prerequisite.

Should I charge during validation?

Yes, if you can. Charging money is the strongest validation signal there is. A pre-order, a deposit, or a paid waitlist tells you that someone values the future product enough to part with cash today. "I'd buy this" in a conversation is the weakest signal. The bigger the commitment you can ask for, the more confident you can be in the result.

How many customer interviews are enough?

Quality matters more than count. Five conversations with the right people will teach you more than fifty with whoever happens to respond to your survey. Stop interviewing when you stop hearing new information. When the same themes, objections, and language patterns keep showing up, you've saturated the signal. That usually happens around 8–12 good conversations.

Can AI replace customer interviews?

No. AI can help you prepare for interviews, generate questions, and analyze feedback. But AI cannot tell you whether your specific audience will pay for your specific solution. Validation requires real signals from real people: money, time, or behavior change. Use AI to make validation faster and sharper. Don't use it as a substitute for evidence only the market can provide.

What's the difference between this checklist and market research?

Market research tells you what a market looks like on paper: size, growth rate, demographics. This checklist tells you whether your specific product will succeed in that market. The checklist is closer to the actual transaction. It's evidence that someone will buy what you're building, not evidence that the category exists.

What if I get stuck on one stage?

That's information. If you can't find people who have the problem, the problem might be too rare. If you can find them but can't start a conversation, your positioning needs work. If they won't pre-order, the value proposition is unclear. If you can't build a prototype, the scope is too big. Don't skip past the stage where you get stuck. That stage usually determines whether the business works.

Should I use this checklist before or after talking to potential cofounders?

Both conversations matter, in different ways. Talk to cofounders early to make sure you share vision and commitment. Talk to customers early to make sure the idea has legs. The worst outcome is committing to a co-founder before realizing nobody wants the product.

For a deeper framework on each validation stage and how they connect, see How to Validate a Startup Idea Before Building — the checklist above is a condensed companion to that article. If your product is a SaaS or micro-SaaS, the same checklist applies with a recurring-revenue overlay that the SaaS-specific pillar — How to Validate a SaaS Idea Before You Build It — walks through in detail. For an AI product, add explicit tests for output quality on real cases, model-layer dependency, cost to serve, and defensibility using How to Validate an AI Startup Idea. For a side-by-side view of where the two vertical checklists overlap and where AI adds three extra columns, see AI Startup vs SaaS Startup: How Validation Is Different.

Bringing it all together

If you only do one thing this week, do this: pick the riskiest assumption in your idea. Write it down. Design the cheapest experiment that could prove it wrong. Run it in the next seven days.

You don't need certainty. You need less uncertainty than you had yesterday. Every experiment either confirms an assumption or teaches you something you didn't know. Both are wins.

The founders who ship useful things aren't the ones with the best ideas. They're the ones who figure out, cheaply and quickly, which of their ideas deserve the next three months. The hardest part isn't running the experiments. It's being willing to let them change your mind.

If you'd like a structured second opinion on which of these assumptions carry the most risk for your specific idea, Yibud's startup validation analysis can help. The goal isn't to score an idea. The goal is to surface the assumptions you should test first, so you don't waste weeks validating the wrong things.

Take one step this week. Run one experiment. Check off one box. The rest will follow.