How much of an MVP should you build first?

Build the smallest version of the product that lets one real user finish the one job it exists for, and lets you see whether they come back or pay. Everything else waits. The hard part is not building less; it is deciding which single job counts.

What is an MVP, in plain words?

MVP stands for minimum viable product. It is a working product with just enough in it to test your biggest assumption with real people. "Minimum" means few features. "Viable" means it genuinely works, so a user can get a result and you can learn from what they do.

A common mistake is to treat the MVP as a cheap, rough copy of the final product. It is better to treat it as an experiment. You pick one question, such as "will clinics in Pune pay to automate appointment reminders?", and build only what is needed to answer it.

How do you decide what goes into the first version?

Start with one sentence: who is the user, what job are they trying to finish, and what does done look like for them? If you need two sentences, you probably have two products.

Then walk the shortest path from the user arriving to the user getting the result. Write each step on a card. A fee-collection tool for tuition classes might look like this: parent receives a link, sees the amount due, pays by UPI or card, gets a receipt, and the teacher sees who has paid. That is five steps. Each step either appears in version one or you have a manual way to cover it.

A simple test for each feature: if we removed this, could the user still finish the job? If yes, it is a later feature.

Which features can usually wait?

These are the ones that tend to creep in early and slow things down:

• Admin dashboards with many filters and charts. A spreadsheet export is often enough at first.
• Several user roles and permission levels. Start with two at most.
• Notifications on every channel. Pick the one your users already read, which in India and the Gulf is often WhatsApp or email.
• Social login, referral programmes, in-app chat and badges.
• A second platform. Choose web or mobile first, not both. Our note on native versus cross-platform apps covers that choice.

None of these are bad ideas. They are just not the experiment.

What should an MVP include even though it is not exciting?

Some unglamorous parts are worth building from day one because they are painful to add later:

• Sign-in that works and a way to reset a password.
• Basic analytics, so you can see where users drop off. Without this, you cannot learn from the MVP at all.
• Backups and a staging copy, so a mistake does not wipe out your first users' data.
• A privacy notice and consent where you collect personal data. India's Digital Personal Data Protection Act, 2023 expects a notice (section 5) and consent (section 6) for processing personal data, so it is easier to design this in than to retrofit it.
• Error logging, so you hear about a failure before your user does.

If money changes hands, include a real payment flow and think about GST invoices for Indian customers or VAT for Gulf customers early. Our guide to what a SaaS product needs before its first paying customer goes through this.

Should you test the idea by hand before building software?

Often yes. Two approaches are widely used.

In a concierge version, you deliver the service by hand to a handful of customers, using WhatsApp, a spreadsheet and your own time, and learn what they actually ask for. In a Wizard of Oz version, the user sees a simple interface while you do the work behind it manually.

Both let you test demand well before you write much software, and both show you which steps are worth automating first. If five customers will not use the manual version, software will not fix that.

How do you keep the scope from growing?

Write the scope down as a list of "in" and "out", and share it with everyone involved. When someone asks for a feature, add it to a "later" list with a note on what you would learn from it. Review that list after launch, with real usage in hand.

It also helps to fix the question the MVP answers and a date to review it. For example: "After 30 days with 20 clinics, do at least half of them still send reminders through it every week?" A clear review point stops the MVP from turning into an endless build.

How do you know the MVP is done?

It is done when a new user can go from arriving to the core result without your help, and you can see from your analytics what they did. It does not need to look finished everywhere. It needs to be reliable at the one thing it does.

After launch, talk to users within the first week. Watch where they hesitate. Their behaviour will settle most of your roadmap debates.

What if you are not sure what the scope should be?

Then the scope is the first thing to work on, before any code. A short discovery stage, with user conversations, a prototype and a written build plan, costs far less than building the wrong thing. You can read how we run it in MVP development and under Product Development.

This is the kind of work we do in Product Development, usually starting with a Product Discovery Sprint so you have a scope you believe in before a build begins. If you want to talk it through, Let's Talk.