I have watched more than a hundred founders in Nepal build an MVP. Here is what I have learned: the ones who succeed usually spend longer on the questions than on the build. The ones who fail do the opposite.

An MVP is not a smaller version of your product. It is a test. And like any test, it only works if you know what you are testing for.

Before you write a single line of code, answer these seven questions. If you cannot, you are not ready to build.

1. What is the one job your MVP needs to do?

Every product does many things. Your MVP should do one. Not two. Not three. One.

The mistake most founders make is trying to show everything the product could become. Investors will not be impressed. Customers will be confused. And your developers will spend three months building features no one uses.

Pick the single most important job. The one that, if your product disappeared tomorrow, your customer would actually miss. Build that. Nothing else.

For a Nepali example: a restaurant booking app does not need reviews, loyalty points, and delivery in version one. It needs to get someone a table. That is it.

2. Who is the smallest group of users you can test with?

Your first 10 users matter more than your next 1,000. They will tell you what is broken, what is confusing, and what you got wrong. But only if you pick them carefully.

Do not launch to everyone. Launch to a group you can talk to personally. Founders who do this get 10x more useful feedback in the first month than founders who chase downloads.

Small is not a weakness. It is a strength.

3. What does success look like in week one?

Numbers force honesty. If your MVP launches and 50 people sign up, is that a win? A failure? You will not know unless you defined it before launch.

Write it down. “I want 20 paying users in the first two weeks.” “I want 100 signups and a 15% activation rate.” The specific number matters less than the act of choosing one.

After launch, you will know immediately whether you hit it. And whether to keep going.

4. What will you do if no one uses it?

This is the question no one wants to ask. But if you cannot answer it, you are not ready to build.

If no one uses the MVP, you have three options: pivot the product, pivot the audience, or stop. Each is valid. Each is easier if you planned for it.

The worst outcome is building for six months and only then asking yourself what went wrong. Plan the failure scenario before you launch. It is the only way to survive it.

5. How much money are you willing to lose?

Be specific. Rs 50,000? Rs 2 lakh? Rs 5 lakh? Whatever the number is, write it down and treat it as a hard ceiling.

Most Nepali founders I know built their first MVP with personal savings. There is nothing wrong with that. What is wrong is spending more than you planned, and then spending more again, hoping the next feature will fix it.

Set a budget. When you hit it, stop and reassess. Do not move the goalposts.

6. What is the fastest thing you can ship?

Not the best thing. The fastest.

If you can build a working product in two weeks instead of two months, do it. You will learn more in those two weeks of live usage than in two months of development.

Skipping “polish” is not cutting corners. It is buying feedback. And feedback is the only thing that matters in the early days.

7. If this MVP fails, will you know why?

The best MVPs fail with useful information. The worst ones fail silently, and the founder walks away with no idea why.

Before you build, decide what you will measure. Signups? Retention? Payment? Use every event as a data point. If your MVP fails, you want to walk away knowing exactly which assumption was wrong.

The Uncomfortable Part

None of these questions are hard. What is hard is answering them honestly before you build.

If you cannot answer question one, you should not be building. If you cannot answer question four, you should not be building. If you cannot answer question seven, you are not building a product. You are building a hope.

Hope is not a strategy. Questions are.