The phrase “minimum viable product” has been around long enough that everyone uses it and almost nobody means the same thing by it.
In my experience running a mobile app development company, when a founder says MVP they usually mean a smaller version of the full product. Same features, less polish. That is not what an MVP is, and building one is how first time founders spend their entire budget before learning anything.
An MVP is the smallest thing that tests whether your assumption is true. It’s an experiment with a user interface. If it doesn’t test something, it isn’t minimum and it isn’t viable, it’s just unfinished.
The vocabulary around this has multiplied. Proof of concept, prototype, MVP, pilot. They’re genuinely different things. A proof of concept tests whether something can be built. A prototype, often clickable in Figma and never shipped, tests whether the interaction makes sense. An MVP tests whether people want it, which requires real users and real usage. Confusing them is how a founder ends up paying production build prices for something that should have been a Figma prototype and two weeks of customer interviews.
Here’s where the scoping usually goes wrong and what to do instead.
Nobody writes down the assumption
Before you can cut features, you need to know what the app is for. Not the vision. The specific belief that, if wrong, means the business doesn’t work.
For a marketplace it might be that sellers will list without being paid to. For a subscription app it might be that people will pay monthly rather than use a free alternative. For a B2B tool it might be that the buyer will change an existing workflow.
Write that sentence down before scoping. Then every feature gets one question: does this help test the assumption? Most don’t.
Founders resist this because the assumption feels obvious to them. It always does. That’s what makes it an assumption rather than a fact.
The admin panel eats the budget
This is the single most common budget surprise, and it’s almost invisible in the original brief.
A founder describes a consumer app. Users browse, search, book, pay. The quote covers that. Then somewhere in week three it emerges that somebody needs to approve listings, manage users, handle refunds, edit content, and see what’s happening.
Building all of that properly can consume a large chunk of a first version budget, and none of it is seen by a single customer.
At MVP stage you usually don’t need it. If you have fifty users, you can manage them from the database. You can approve listings manually. You can process a refund through the payment gateway dashboard. It’s unglamorous and it doesn’t scale, and neither does anything else about a business with fifty users.
Build the admin panel when the manual work becomes genuinely painful, which is a real signal that you have traction. Building it before then is spending money to make a problem you don’t have easier.
Features founders always insist on that nobody uses in month one
Some patterns repeat across almost every project.
In app chat. Almost always requested, almost never used at low volume. Users message on WhatsApp anyway, especially in India. A phone number or a WhatsApp link solves this until you have enough volume to justify the build, and it takes an afternoon rather than three weeks.
Social login with every provider. Google, Apple, Facebook, phone, email. Each one is integration work, testing surface and a support burden. Pick the one your users actually have. For most Indian consumer apps that’s phone. For most B2B tools it’s Google. One is enough at the start.
Notifications for everything. A full notification system with preferences, categories, in app inbox and history is a substantial feature. At MVP stage you need push for maybe two events, and you can add the rest once you know which ones people care about.
Referral and rewards programmes. Built before there’s anyone to refer anyone. Referral works when you have users who love the product, which is the thing you haven’t established yet.
Multi language support. Real internationalisation touches every screen and adds cost to every future change. If your first users are in one city speaking one language, ship in that language.
Ratings and reviews. Needs moderation, needs enough volume to be meaningful, and looks broken when it’s empty. Wait.
None of these are bad features. They’re all fine features at the wrong time.
The two sided marketplace trap
If you’re building a marketplace, the MVP question is harder than usual, because you have two audiences and the product is worthless without both.
The common mistake is to build both sides fully and launch to an empty market. Sellers arrive, see no buyers, leave. Buyers arrive, see no sellers, leave.
The workable pattern is usually to build one side properly and fake the other until it’s real. Seed supply manually. Onboard the first sellers yourself, by phone, entering their listings for them if necessary. It doesn’t scale, and it doesn’t need to, because you’re testing whether buyers want what’s on offer, not whether your seller onboarding flow is elegant.
Which means the seller app you were about to spend two months building might not need to exist yet. A shared spreadsheet, a WhatsApp group and an admin form will carry you a long way.
This is the concierge MVP pattern, where you deliver the service manually behind a product-shaped front end. Its cousin is the Wizard of Oz approach, where the user sees automation and a person is doing the work. Both feel like cheating and both produce better learning per rupee than building the real thing.
What actually belongs in version one
A useful test: could a stranger complete the core action, end to end, without you helping them?
For most apps that’s a short list. A way in. The core action. Whatever is needed to complete it, including payment if money is involved. Enough analytics to know what happened. Some way for users to tell you something is broken.
That’s it. Everything else is version two.
The analytics point is worth emphasising because it gets cut when budgets tighten, and it’s the one thing you genuinely cannot add later without losing the data you needed. Launching without instrumentation means your experiment produces no result. You’ll know how many people downloaded it and nothing about what they did.
Given the retention environment, that matters. Compiled 2026 benchmark data across the industry puts median day thirty retention at roughly 4%. If you launch blind, you’ll see users disappear and have no idea at which screen.
Say the timeline out loud
A rough rule that has held up across projects: an MVP that takes more than three months to build has stopped being an MVP.
Not because three months is magic, but because of what the number reveals. If the scope needs six months, either the assumption being tested is too broad, or a smaller test exists and hasn’t been found yet.
Long timelines also carry a hidden MVP app development cost. The market moves, the founder’s thinking moves, and by month five you’re building something the founder no longer believes in but can’t stop because it’s half built.
How to have the conversation with your developer
If you’re commissioning the work, a few things make this go better.
Give the assumption, not just the feature list. A good development partner will suggest cuts if they understand what you’re testing. If they only have a feature list, they’ll quote the feature list, because that’s all they can do.
Ask which items in the quote could be deferred to version two, and what each one costs. Any competent agency can answer this in a meeting. If they can’t, or won’t, that tells you something.
Ask what happens if the assumption turns out to be wrong. If the honest answer is that most of the build is thrown away, the scope is too big.
And be careful about the opposite failure. Cutting so aggressively that the app doesn’t do its job produces a test result you can’t trust. If users leave because the app was frustrating rather than because they didn’t want the product, you’ve learned nothing and spent money to learn it.
The line you’re looking for is small but complete. Not a fragment of the vision. The smallest whole thing that works.
