Introduction
For many founders, asking how much an MVP costs is not casual research.
It is a question sitting next to a savings account, a conversation with a spouse, an unused credit limit, a possible loan or money borrowed from someone who believes in them.
That is why vague answers such as “it depends” are frustrating. Of course it depends. The useful question is: what does it depend on, what can different budgets realistically achieve, and how do you avoid spending on the wrong things?
There is no single correct price for an MVP in India. A focused product that tests one workflow is fundamentally different from a two-sided marketplace, a fintech system, an AI document processor or a mobile application with live tracking.
Still, founders deserve more than a mysterious quotation produced after a 30-minute call.
First, What Does “MVP” Actually Mean?
An MVP is not simply a cheaper version of the final product. It is the smallest responsible release that allows you to test an important business assumption with real users.
It should be:
- Minimum: limited to the fewest capabilities required for the test.
- Viable: reliable enough for the intended users and context.
- A product: a complete workflow, not a disconnected collection of screens.
If users can register but cannot reach a meaningful outcome, you do not have an MVP. You have authentication.
If customers can place an order but your team cannot view or fulfil it, the workflow is incomplete.
If the product handles financial or sensitive information without proper access controls, “minimum” has been confused with careless.
Realistic MVP Budget Bands in India
These are planning ranges, not fixed price cards. The final cost depends on product scope, technical risk, integrations, design depth and release responsibilities.
₹1.2 lakh to ₹2.5 lakh: prototype or tightly scoped validation build
Craftnotion's current MVP service starts at ₹1.2 lakh. At the lower end of this range, the scope has to remain deliberately narrow: usually one user type, one central workflow, limited administration and few or no complex integrations.
This range may cover a working validation product, internal tool, prototype with selected production capabilities or a tightly bounded web application. It should not be read as a promise that every business-ready MVP can be delivered for ₹1.2 lakh. The actual scope still determines the estimate.
₹2.5 lakh to ₹5 lakh: focused validation MVP
This range can suit a product with:
- One primary user type
- One central workflow
- Standard authentication
- A focused web application or relatively contained mobile experience
- Basic administration
- Limited third-party integrations
- Simple reporting
- A restrained custom design system
Examples might include an internal request portal, a simple appointment flow, a focused learning tool, a quotation workflow or the first usable version of a niche SaaS product.
The important constraint is focus. This budget cannot responsibly include every imagined user role, advanced automation, complex AI, real-time tracking, a large marketplace and “just a small admin panel” that quietly contains half the product.
₹5 lakh to ₹10 lakh: operational MVP
This range is more appropriate when the first release needs:
- Multiple user roles
- Web and mobile experiences
- Payments or subscriptions
- Operational dashboards
- Notifications
- Several integrations
- More detailed permissions
- A stronger administration system
- Production deployment and release support
At this level, the MVP may support a small but real business operation rather than only testing interest.
₹10 lakh to ₹20 lakh or more: complex first release
Some products are structurally complex even when the feature list looks short.
Costs rise when the product involves:
- Financial transactions or regulated workflows
- Large data migrations
- Healthcare or other sensitive information
- Real-time communication or location tracking
- Two-sided marketplaces
- Complex approval chains
- AI evaluation, human review and exception handling
- Offline behaviour
- Multiple mobile applications
- Deep integrations with existing systems
Calling such a product an MVP does not remove its engineering responsibilities. A small aircraft is still an aircraft; removing half the bolts does not make it lean.
What Actually Changes the Cost?
1. Number of workflows, not number of screens
Ten informational screens can be easier than one screen coordinating payments, inventory and three user roles.
Estimate the product by what users and systems must accomplish, not by counting Figma frames.
2. User roles and permissions
A customer, service provider, manager and administrator may see the same record differently and be allowed to perform different actions. Every additional role creates rules, states and testing responsibilities.
3. Web, mobile or both
A responsive web product may be sufficient for the first release. Separate Android, iOS and web experiences increase design, development, testing and release effort.
Choose platforms based on user behaviour, not because successful companies eventually have all three.
4. Integrations
Payments, WhatsApp, maps, accounting software, identity providers, CRMs and external APIs can save enormous development effort. They also introduce vendor limitations, usage fees, approval processes and failure cases.
“Connect an API” is rarely one checkbox.
5. AI functionality
An AI feature needs more than an API call. The product may require prompt and model evaluation, structured outputs, review screens, fallback behaviour, usage limits, privacy decisions and monitoring.
If an incorrect answer could cost money or harm a customer, human review and auditability become part of the product.
6. Design depth
A clear, consistent MVP still needs design. However, there is a difference between a focused product interface and a large custom design system with complex motion, illustrations and dozens of states.
Good design is not decoration. It decides whether users understand the workflow. But the first release does not need to win an animation award while the business model remains untested.
7. Administration and operations
Founders often focus on the customer-facing experience and discover late that their own team needs to:
- Approve users
- Correct records
- Process refunds
- Review flagged activity
- Export data
- Manage content
- Respond to support issues
- Understand what happened when something failed
The admin side is not automatically “basic.” It is where the business operates.
Costs Commonly Forgotten in the First Budget
The development quotation is not the complete cost of running a product.
Plan for:
- Cloud hosting and databases
- Email, SMS and WhatsApp usage
- Payment gateway charges
- Maps and third-party APIs
- App-store accounts
- Domain and business email
- Analytics and monitoring
- Customer support
- Maintenance and security updates
- Marketing and user acquisition
- Legal, privacy and compliance advice where required
A sensible first-year budget separates building the product from operating and learning from it.
Why Two Quotations Can Be Wildly Different
One team may assume polished designs, proper testing, deployment, project management and post-launch support.
Another may quote only development based on a short feature list.
The lower quotation is not automatically wrong, and the higher quotation is not automatically better. Compare what is actually included:
- Who defines the requirements?
- Is UX and interface design included?
- Are edge cases and error states covered?
- Is an admin system included?
- Who owns deployment?
- Is testing included?
- Are source code and accounts handed over?
- What happens after launch?
- How are scope changes handled?
Without these answers, comparing quotations by total price is like comparing flights without checking the destination.
How to Reduce Cost Without Damaging the Product
Begin with one user and one outcome
Choose the person whose problem is most urgent and design one complete workflow for them.
Use manual operations behind the scenes
Automate only what must be automated for the test. Your team can manually review, approve or coordinate some early transactions.
Use existing infrastructure
Payments, authentication, messaging and content management usually do not need to be invented again.
Delay secondary platforms
If a responsive web application can test the business, mobile applications can follow after evidence appears.
Separate uncertainty from complexity
Some features are expensive because they are technically difficult. Others are expensive because nobody has decided how they should work. Product discovery reduces the second kind.
A Better Way to Decide Your MVP Budget
Start with three numbers:
- Maximum responsible investment: the amount you can risk without putting yourself or the business in a dangerous position.
- Learning objective: the assumption this release must test.
- Runway after launch: the money and time available to operate, market and improve the product.
Do not spend the entire available amount on version one. A product usually needs observation and correction after real users arrive.
If ₹5 lakh is your complete available budget, building a ₹5 lakh application and leaving nothing for acquisition, support or improvement is not a complete plan.
Red Flags During Estimation
Be cautious if:
- A final price is promised before anyone understands the workflow.
- Every feature is accepted without challenge.
- The quotation does not state what is excluded.
- Ownership of code and infrastructure is unclear.
- There is no plan for testing or deployment.
- The timeline sounds suspiciously perfect.
- AI is promised with no discussion of data, accuracy or review.
- The cheapest quotation is justified only by saying everything is “easy.”
You are not looking for the team that agrees fastest. You are looking for the team that helps you see the product more clearly.
You Can Discuss the Budget Before Everything Is Figured Out
Founders sometimes hide their budget because they fear the quotation will magically expand to consume it. That concern is understandable.
But a genuine budget range helps a responsible team propose the right first version. The same idea might be tested with a prototype, a manual pilot, a web MVP or a fuller operational product. Those are different plans, not discounts on the same plan.
At Craftnotion, we would rather reduce a first release than pretend every requested feature fits safely into an unrealistic budget. If you are trying to understand what your idea might cost, send us the problem, the users, the workflow and the range you are comfortable exploring.
We can help you separate what must exist now from what can wait—and give you a clearer view of the effort before you commit your money.
