Table of Contents
- Introduction
- 1. What Do You Need to Validate With This MVP and What Metrics Will Tell You If You've Succeeded?
- 2. Who Is Your User and What Specific Problem Do They Have?
- 3. Do You Already Have Potential Users to Talk To Before Building?
- 4. What Is Your Real Budget?
- 5. What Does Success Look Like for You?
- The Cost of Not Asking These Questions
- Checklist Before You Write Code
- Conclusion
Introduction
I've talked to hundreds of founders. Most arrive with a brilliant project in mind, months of prior work, excitement, a well-thought-out business plan.
And the first thing I do is ask them to wait.
Before writing a single line of code, I need to ask them five questions. They're not questions about technology. It doesn't matter if they'll need an app or a web platform, if the backend will be in Node or Python, how the database will scale.
All of that comes later.
What I need to understand first is whether they're actually ready to build. Because most MVPs that fail don't fail because of code or technical decisions. They fail because they never honestly answered these five questions.
And you won't know that until it's too late.
1. What Do You Need to Validate With This MVP and What Metrics Will Tell You If You've Succeeded?
This is the most important question. And the one most founders answer poorly.
Most say: "I want to validate that people need my product." That's not specific enough.
What you need is a hypothesis. Concrete. Falsifiable. With a number.
It's not: "Users will use it."
It's: "Within 6 weeks, 50 active users will perform three searches weekly on average, and at least 20% of them will pay €9 monthly."
That's a metric. That tells you whether you failed or validated.
Without this answer, your MVP has no clear endpoint. And it's doomed to fail. Because after three months of work, you won't know whether you should pivot, iterate more, or stop completely.
The metric is what distinguishes between an MVP that validates and one that just consumes resources.
Ask yourself:
- What's the exact number that would tell me "this worked"?
- How long do I expect it to take to reach that number?
- Where will that number come from? (users, revenue, retention, activity, something else)
If you can't answer those three questions clearly, you're not ready.
2. Who Is Your User and What Specific Problem Do They Have?
I've seen countless brilliant product presentations. The founder describes the solution beautifully. Everything sounds great.
Then I ask: "What problem are you solving for your user?"
And the answer is vague. Or describes the founder's problem, not the user's.
A real user has a concrete problem. Not a general problem. A problem that hurts. That costs them money. Or time. Or makes them fail.
If your user is "graphic designers" and your problem is "they need a tool to collaborate," that's too broad.
If your user is "freelance graphic designers working with 5+ simultaneous clients" and your problem is "they lose 3 hours weekly resolving feedback from multiple clients across different channels (email, Slack, WhatsApp, Drive comments)," then you have something specific.
The specific problem is what lets you build a focused MVP. It's what lets you discard features that don't contribute. And it's what lets you talk honestly with potential users.
Without this clarity, your MVP will have a little bit of everything. And in the end, it won't solve anything for anyone.
3. Do You Already Have Potential Users to Talk To Before Building?
This is the question I see the most resistance to.
"Why do I need users before building? The MVP is for validating with users."
Technically true. But not having users is a huge red flag.
If you can't find even 5 people outside your family who say "yes, that problem hurts me, I'd like to try it when it's ready," there's a problem.
Building blind is probably the most expensive mistake you can make at this stage. You'll spend 3 months building something, and when you launch, you'll discover nobody wanted it.
What you need before writing code is contact with potential users. It doesn't need to be formal. It doesn't need to be a 50-person survey. It needs to be real conversations with people who live the problem.
If you can't find those 5 people in your network, maybe the problem isn't universal enough.
And that's valuable information. Better to know now.
4. What Is Your Real Budget?
Not the budget you'd like to have. The budget you actually have right now.
And the budget you have to dedicate entirely to the MVP. Not money you hope comes from elsewhere. Money you have now.
Because without that number, it's impossible to prioritize what goes into each phase and what has to wait.
An MVP with €5,000 is very different from an MVP with €50,000.
With €5,000, you probably can't build a polished product. You can build something functional that solves the problem. And that's fine. That's an MVP.
With €50,000 you can iterate more. You can build a product with better UX. You can do better onboarding.
But your budget really determines what's possible to build. And that determines what you can validate.
If your budget is €5,000 and your plan requires €30,000, then you don't have a plan. You have a fantasy.
You need to adjust scope. Or get more budget.
But most founders never have this conversation. So after two months they run out of money. And the MVP stays half-finished.
5. What Does Success Look Like for You?
I've seen cases where a founder considered his product validated with 30 users. And others who couldn't keep going even with 30,000.
The difference isn't in the number. It's in whether that number confirms or rejects the hypothesis.
Without a clear answer to this question, your MVP has no clear endpoint. It's doomed to fail.
Because at month 4, when you've spent your budget and have data, you won't know if it was a success or failure. And that's wasted money.
What you need is a clear definition of what success means.
Not in general terms. In numbers.
"MVP succeeded" could mean:
- 50 active users in 6 weeks
- Weekly retention rate of at least 30%
- At least 5 users willing to pay before date X
- 100+ clicks to "call for demo" in two weeks
- 10 letters of intent to purchase
Whatever it is. But it has to be a metric. A number. Something you can measure objectively.
If you don't have that definition, when you finish your MVP, you won't know whether to pivot, iterate, or stop.
The Cost of Not Asking These Questions
I've been watching this for years. Founders who build for months without answering these questions. They spend money, time, energy.
And when they finally launch, they discover that:
- The problem they solved isn't the one the user had
- Users aren't willing to pay
- The product has a hundred features but none solves anything well
- There's no clear way to say whether it worked or not
And at that point, the MVP is dead. And all the money is gone.
Most projects that fail don't fail because of code.
They fail because nobody asked these questions before starting.
And when you ask too late, the cost is no longer technical. It's time, money, and lost opportunities.
Checklist Before You Write Code
Before you start building your MVP, sit down and honestly answer these five questions:
- What is the exact metric that will tell you if you validated your hypothesis?
- Who is your user exactly and what is their specific problem?
- Do you already have contact with at least 5 potential users?
- What is your real available budget right now?
- What exact number will tell you "the MVP worked"?
If you can answer these five questions clearly, concretely, and honestly, you're probably ready to build.
If you can't, you might not be yet.
And recognizing it now is better than finding out in six months when the money runs out.
Conclusion
Someone once told me: "The difference between a startup that works and one that fails isn't the idea. It's the execution."
That's probably true.
But I think there's something before execution. There's clarity about what exactly you're trying to achieve.
If your MVP is vague, it will fail. But not because of code. Because of lack of focus.
These five questions are what give you that focus.
If you need help answering these questions before you start building, or you need a technical audit to evaluate whether your MVP is viable, we can talk with no strings attached. I have a framework that helps you validate your idea in less than a week.
It's not a long process. It's an honest conversation about whether you're really ready.