The core idea
An MVP is not a cheap version of your product. It is the smallest thing that tests your riskiest assumption. If it does not do that, it is not minimal and it is not viable — it is just unfinished.
Bengaluru is full of well-funded MVPs that took nine months, cost ₹40 lakh, and validated nothing — because they were built to impress investors rather than to answer a question. Here is how to avoid that.
Find your riskiest assumption first
Every startup rests on assumptions. One of them will kill you if it is wrong. That is the one your MVP must test.
| Riskiest assumption | What the MVP must prove | What you can fake |
|---|---|---|
| People want this at all | They sign up and use it | Almost everything behind the scenes |
| People will pay for it | They actually pay | Automation, scale, polish |
| We can deliver it | The hard technical part works | The interface, the onboarding |
| Supply will join | Vendors or drivers sign up | The consumer app entirely |
You can fake more than you think. If your riskiest assumption is demand, a landing page with a working payment link and manual fulfilment behind it tests it for ₹40,000. Many successful companies ran on humans pretending to be software for months.
The scoping exercise that works
- Write the single sentence "This lets [who] do [what] so they can [outcome]." If you cannot write it in one sentence, your scope is not clear enough to build.
- List every feature you imagine Get it all out — typically 30 to 60 items.
- Mark each one Does the single sentence break without it? Only those survive.
- Cut the survivors by half again This hurts, and it is where the real saving is. Most "essential" features are essential to version three.
- Build only what remains Typically 5–10 features and one core workflow.
What almost every MVP can skip
- Admin panels with charts — use a database viewer or spreadsheet initially.
- Multiple user roles — start with one.
- Password reset flows — handle it manually for your first 50 users.
- Native apps for both platforms — ship a responsive web app.
- Payment automation — a UPI link and a manual check works at small scale.
- Notifications, referrals, gamification, social features.
- Elaborate onboarding — call your first users personally instead. You will learn more.
Every feature you build before validation is a bet placed before you have seen the cards.
Realistic MVP budgets in Bengaluru
If a quote for an MVP exceeds ₹12 lakh, ask which features are being built to test an assumption and which are being built because they seem necessary. The second category is where the money is going.
Technical choices that keep options open
Your MVP stack should optimise for changing your mind, not for hypothetical scale:
- Boring, well-known technology. Easier to hire for in Bengaluru, easier to hand over.
- Managed services over custom infrastructure. Firebase, Supabase, Razorpay — do not build what you can rent while validating.
- One codebase, one deployment. Microservices at MVP stage is a self-inflicted wound.
- Analytics from day one. You cannot learn from an MVP you are not measuring.
- Your own repository and cloud accounts. Never let a vendor hold your infrastructure.
Do not optimise for scale you do not have. Architecture designed for a million users costs several times more and slows every iteration. You will rewrite it anyway once you learn what users actually do — and if you succeed enough to need it, you will be able to afford it.
Knowing what the result means
Decide your success criteria before launch, in writing. Vague goals let you interpret failure as promise:
| Weak signal | Meaningful signal |
|---|---|
| Sign-ups | Users returning in week two |
| "People love the idea" | People paid money |
| App downloads | Completed core action |
| Positive feedback | Unprompted referrals |
Planning an MVP? Tell us your riskiest assumption and we will help scope the smallest build that tests it — including telling you when you do not need to build anything yet. See also our platform choice guide.