Build the Smallest Thing That Proves You Right: An MVP Guide for Indian Founders

An MVP is not a cheaper version of your product. It is the fastest test of your riskiest assumption. Here is how to build it, what to leave out, and when to stop building and start selling.

I have watched founders spend ₹10 lakh and six months building a product that nobody had asked for. The code was clean and the design was beautiful. The problem was that nobody had checked whether the problem was real before the build started. When I ask these founders what they learned, the honest answer is usually “not much, until we launched.”

Why MVPs Get Misunderstood

The term “minimum viable product” has been stretched to mean “a version one with fewer features.” That is the wrong definition. An MVP is the smallest experiment that can prove or disprove your riskiest assumption. Its job is to produce evidence, not to be a product you can sell at scale.

If your assumption is that customers will pay, the MVP should test payment, not the dashboard. If your assumption is that the process works, the MVP should test the process, not the app.

Step 1: Find Your Riskiest Assumption

List every assumption your business depends on, then sort them into three groups:

• Desirability: Will people want this?

• Feasibility: Can we deliver it?

• Viability: Will the money work?

The riskiest assumption is the one that kills the business if it turns out to be false. In most early companies, it is desirability or viability. Feasibility is usually the easiest thing to solve, which is why founders start there and never learn anything important.

Step 2: Choose the Right Type of MVP

You do not need a full app to learn. Consider these options first:

• Landing page with a sign-up or pre-order button. Fast, cheap, and a direct test of demand.

• Concierge MVP. You deliver the service manually for a few customers.

• Wizard of Oz. The service looks automated to the customer, but a person is doing the work behind it.

• WhatsApp or spreadsheet service. In India, WhatsApp is often the most natural interface, and the most valuable early data is in the conversations.

• Single-feature build. One feature, done well, that solves the one problem your customers have told you matters.

A logistics idea, for example, can be tested through WhatsApp groups and manual dispatch before anyone writes a line of app code. If the operation works by hand, you have evidence worth building around.

Step 3: Decide What to Leave Out

The list of what not to build is more important than the list of what to build. Most early MVPs do not need:

• A full login and account system

• An admin panel

• Every language and every state on day one

• A payment gateway, if you can invoice by UPI or bank transfer

• Notifications, referral programmes, or loyalty features

Indian customers are price-sensitive, and many are more comfortable in their own language. Serving one language and one segment well is a stronger start than thin coverage of ten.

Step 4: Set a Budget and a Time Box

Give your MVP a fixed budget and a deadline, usually four to six weeks. If the MVP costs more than three months of your runway, your scope is wrong. Cut the scope, not the rules.

The research supports this discipline. In a study of Indian startups, inadequate sales and marketing strategy, which leads businesses to fall behind rivals and lose money on each transaction, was one of the most common failure factors. An expensive build with no sales plan is how that happens.

Step 5: Know When to Stop Building

Here is the rule I give founders: keep building only until one user performs the core action without you asking twice. Once a customer does the thing you hoped for, unprompted, you have enough to keep going. From that point, every extra feature is a guess. Stop building and start selling.

Measure one thing that matters: repeat use, a paid pilot, a referral, or money. Pick the metric before you launch.

The 2026 Trap

AI-assisted tools have made building much faster and cheaper. That is good news, but it creates a trap. You can now build the wrong thing in weeks instead of months. Speed is no longer the advantage. The advantage is choosing what to build, and when to stop.

Your Next Step

Write down your riskiest assumption. Design the smallest test that could disprove it within four weeks. Set a budget you cannot exceed. Then go and find ten people who will use it before you write another feature.

The strongest startup you will ever build is yourself, and the discipline to test before you build is part of that.