Most founders start building too early.
Not because they're impatient (though that's part of it). Because nobody told them what "ready to build" actually looks like.
After working with dozens of pre-seed founders, here's the checklist we go through before we write a single line of code. These 27 items determine whether an MVP will succeed — and most of them cost nothing but time.
Table of Contents
- Why This Checklist Exists
- Section 1: Problem Validation (Items 1-7)
- Section 2: Customer Clarity (Items 8-14)
- Section 3: Solution Validation (Items 15-20)
- Section 4: Build Readiness (Items 21-27)
- What the Checklist Tells You
- When to Start Building Before the Checklist Is Complete
Why This Checklist Exists
The most expensive mistake in product development isn't building the wrong thing. It's building before you know what the right thing is.
A $6K MVP that answers the wrong question is $6K wasted. A $6K MVP that answers the right question precisely is one of the best investments a pre-seed founder can make.
The difference between the two is the work you do before the build starts.
This checklist is organized into four sections: problem validation, customer clarity, solution validation, and build readiness. Work through them in order. The later sections don't matter if the earlier ones aren't solid.
Section 1: Problem Validation (Items 1-7)
✅ 1. You can describe the problem in one sentence without using your product name
If your problem description requires explaining your solution, you don't have a clear problem statement yet.
Good: "Restaurant managers spend 3 hours per week manually reconciling delivery platform payouts." Not good: "Restaurant managers need a platform to help them with their delivery operations."
✅ 2. You've talked to at least 10 people who have this problem
Not surveys. Not LinkedIn polls. Real conversations. You've asked them about the problem, heard about their experience, and understood how they currently deal with it.
10 is the minimum. 20 is better.
✅ 3. At least 3 of them described the problem unprompted in the same language you use
If you have to explain the problem to people who supposedly have it, either the problem isn't real or you're targeting the wrong people.
When you're talking to the right people about a real problem, they'll complete your sentences.
✅ 4. You know what people currently do instead of using your product
There is always a current solution — even if it's "we just don't do this" or "we do it manually in a spreadsheet." Know what it is. Your product has to be meaningfully better than the current solution, not just different.
✅ 5. You've quantified the problem
How much time does it waste? How much money does it cost? How often does it happen? How many people have it?
Investors ask this. Users evaluate it. You should know it.
✅ 6. The problem is getting worse, not better
Problems that existing solutions are solving are getting easier to ignore. Problems that are getting worse because of market forces, technology changes, or regulatory shifts are getting more valuable to solve.
Know which direction your problem is trending and why.
✅ 7. You've confirmed the problem exists in the market segment you're targeting
A problem that exists for large enterprise companies may not exist for SMBs. A problem that's acute in the US may not exist in Europe. Validate that the problem exists specifically for the people you plan to sell to.
Section 2: Customer Clarity (Items 8-14)
✅ 8. You can describe your first customer in one sentence
Not a market segment. A person.
Not ready: "Our customers are B2B SaaS companies." Ready: "Our first customer is the head of revenue operations at a B2B SaaS company with 20-100 employees that is using more than 5 sales tools and struggling with attribution."
✅ 9. You know specifically why they would buy now
There's a reason buyers act at certain moments and not others. What's happening in their life or business right now that makes them ready to buy?
Triggers: new job, new funding round, new regulation, failed attempt with a different solution, competitor gaining ground.
✅ 10. You know who decides and who pays
In B2B, the person with the problem is often not the person who signs the check. Know who you're selling to, who approves the purchase, and what their objections will be.
✅ 11. You know what a successful outcome looks like for them
Not "they use your product." What does the world look like for them 90 days after they start using your product? What's different? What can they do that they couldn't do before?
✅ 12. You know how they currently evaluate solutions like yours
Do they search Google? Ask colleagues? Look on G2 or Capterra? Read newsletters in their industry? Your go-to-market strategy depends on understanding how they find solutions today.
✅ 13. You know what they've already tried
Most people don't buy the first solution they try. They buy the solution after they've failed with alternatives. Know what your customer has already tried and why it didn't work. This tells you where your real differentiation needs to be.
✅ 14. At least one potential customer has said they would pay for what you're building
Not "I'd definitely check that out." Not "sounds interesting." Payment intent. "I would pay $X per month for something that does Y."
If nobody has said anything like this, you haven't validated demand — you've validated that people are polite.
Section 3: Solution Validation (Items 15-20)
✅ 15. You've tested the core assumption with a no-code or manual version
Before building, can you test the core assumption with a spreadsheet, a manual process, or an existing tool? Many successful startups operated their core workflow manually before automating it.
The goal of an MVP is to validate the assumption. Sometimes you can validate it without building the MVP.
✅ 16. You've shown potential customers a mockup, prototype, or description and they wanted it
Wireframes, Figma mockups, a written description of the workflow — show something to the people who have the problem. Their reaction tells you whether you're solving it the right way.
Watch what they click on, what they ask about, what confuses them. This is more valuable than any spec review.
✅ 17. You know which single feature is the reason someone would pay for this
There's always one thing. The thing that, if it worked exactly right, would make the product worth having. Everything else is supporting. Know what your one thing is.
✅ 18. You've decided what your MVP will NOT have
The out-of-scope list is as important as the feature list. If you don't know what you're deliberately leaving out, you don't have a scope — you have a direction.
✅ 19. You've validated the technical feasibility
If your product relies on a specific API, a specific data source, or a specific technical capability — confirm it exists and is accessible before you build on the assumption that it does.
Founders have built entire MVPs around API integrations that turned out to have rate limits that made the product non-functional at scale, or data sources that required enterprise agreements they couldn't get.
✅ 20. You know what "minimum" means for your MVP
The word "minimum" in Minimum Viable Product does real work. What is the absolute minimum you need to build to test your core assumption with real users?
Not the minimum you're comfortable launching with. The minimum that tests the assumption.
Section 4: Build Readiness (Items 21-27)
✅ 21. You have a written spec
Not notes. A document that describes exactly what you're building — user flows, integrations, success criteria, out-of-scope list. Something a developer who has never spoken to you could read and know what to build.
✅ 22. You know who is building it
Agency, freelancer, co-founder, or yourself. You know the answer and you've had the scoping conversation.
✅ 23. You know how long it will take and what it will cost
Real numbers, not estimates. The agency has given you a quote. The freelancer has given you a timeline. You know the number.
✅ 24. You have the budget available
Not "I will have it soon" or "I'm raising for it." Available now.
✅ 25. You know how you'll get your first 10 users after launch
If the plan is "post on Product Hunt and hope," that's not a plan. How specifically will you get 10 people to try your product in the first 30 days? Who are they, where are they, and how will you reach them?
✅ 26. You know what you'll measure in the first 30 days
Not vanity metrics (page views, sign-ups). The metric that tells you whether the core value proposition is working. Retention, activation rate, usage of the core feature, revenue.
One metric. Know what it is before you build.
✅ 27. You've defined what success looks like at Day 30
If the MVP works, what does Day 30 look like? What do the numbers say? What do users say? What happens next?
If the MVP doesn't work, what does Day 30 look like? What will you do?
Having answers to these questions before you build means you'll know what to do when you get there, instead of trying to figure it out in the middle of a launch.
What the Checklist Tells You
If you can check all 27 items — you're ready to build. Your MVP has a high probability of producing useful information, regardless of whether the product itself is a success.
If you can't check 10 or more items — don't build yet. The work you're avoiding is cheaper than a failed build.
The most common gaps we see:
- Items 2-3: Founders have talked to people about their idea, not about the problem
- Item 14: No explicit payment intent, just positive reactions
- Items 18, 21: No out-of-scope list and no written spec
- Item 25: No specific plan for getting first users
These gaps don't mean the idea is bad. They mean you need a few more weeks of validation work before the build will be worth the investment.
When to Start Building Before the Checklist Is Complete
There are cases where starting the build before completing the checklist is the right call:
When the market is moving fast and a competitor is building. Sometimes speed matters more than perfect validation. Build with the validation you have, learn fast.
When you're a technical founder building for yourself. If you have the problem, you understand it deeply, and you're building for your own use case — your validation can come from your own experience.
When you've validated in a previous company. If you've solved this problem before in a different context, you can borrow the validation from that experience.
When you have pre-committed customers. A letter of intent or a paid pilot from a real customer is stronger validation than any amount of interview work.
Outside these cases — do the checklist work first. The build will be better for it.