MVP cost guide
What an MVP really costs to build
An MVP has no standard size, so the useful answer is a scope conversation: what has to be true before you would keep going, and the smallest thing that could prove it.
Get a scoped estimateWhy two quotes for the same idea look nothing alike
Ask three studios to quote the same one-page brief and you will get three different products: one reads it as a clickable demo for a fundraise, another as something that takes card payments from strangers and survives a bad week. The brief never said which. Each priced the version it had built before.
The question that moves the answer most is what has to be true before you would keep going. If it is "someone paid us", you have signed up for accounts, payments, refunds and support. If it is "thirty people used it twice in a week", you may not need a backend at all.
Cost drivers
What actually moves the number
None of these appear on a feature list. They are the decisions that quietly double a build, and most of them can be deferred once someone points at them.
User roles and permissions
A customer, an admin who can issue refunds, and a support agent who must not see card details. Each role adds screens and its own tests.
Taking money
A hosted checkout page is quick work. Subscriptions with proration, failed-payment retries, invoices and a working refund path are a build of their own.
Web, mobile, or both
Shipping to the App Store adds review cycles, a release process, push notification setup and a rejection you cannot schedule around. Web deploys the same afternoon.
Integrations you do not own
Connecting to a client's SAP instance or a bank's sandbox sets your pace, not ours. Credentials routinely arrive weeks after the kickoff call.
Design, invented or adapted
Adapting a component library takes days. An original design system with its own motion, illustration and empty states is a parallel project beside the build.
Bringing your existing data in
That spreadsheet of customers has duplicate emails, three date formats and a column somebody used for notes. Cleaning it is real work, and nobody volunteers.
Compliance and data rules
A GDPR deletion request has to actually delete the row, the backup and the analytics event. Health or KYC data changes the hosting decision entirely.
AI features that have to be right
A model in a demo is an afternoon. A model whose wrong answers reach a customer needs an evaluation set and a fallback path.
The admin panel nobody quotes
Someone at your end has to refund an order, reset a password and fix a typo. Without that screen, each one becomes a developer ticket.
Scope tiers
Four honest versions of the same idea
Every tier is quoted to your scope and your budget. What changes between them is not quality — it is how much of the product exists on day one.
- TIER 1 — PROTOTYPE
- Clickable prototype, no backend. Ships in 2-3 weeks.
- ₹1L – ₹1.5L$1.1k – $1.7k
- Designed screens wired into a walkthrough you can put in front of users or investors, with the core flow decided. Suits validating a concept before committing. Does NOT include accounts, a database, payments or anything a real user could sign up for.
- TIER 2 — SINGLE-FLOW MVP
- One core flow, live users. Ships in 6-9 weeks.
- ₹5L – ₹7L$5.7k – $8k
- Signup, the one job the product exists to do, basic usage analytics and a deploy pipeline. Suits founders testing whether people will use it at all. Does NOT include payments, mobile apps, an admin panel or a second user role.
- TIER 3 — COMMERCIAL MVP
- Paying customers and support. Ships in 3-4 months.
- ₹14L – ₹18L$16k – $20k
- Accounts, roles, payments with a refund path, transactional email, an internal admin screen and error monitoring. Suits a product that has to take money and hold up unattended. Does NOT include native mobile apps or formal security certification.
- TIER 4 — FUNDED LAUNCH BUILD
- Web plus mobile, integrated. Ships in 5-8 months.
- From ₹35LFrom $40k
- Everything above plus native apps, integrations into systems you do not control, a real design system and a staged rollout. Suits a funded team with a signed pipeline. Does NOT include an enterprise security review or feature work after launch.
Indicative ranges for scoping conversations, not quotes. They reflect what work of this shape has cost us to deliver — your figure comes out of a paid discovery, against a written scope, and is fixed before any code is written. Gas, licences, cloud and third-party audit fees sit outside these numbers.
How we work
How a build actually gets scoped
Timelines below are typical for a first product. The second step exists to shrink the scope, and occasionally to talk you out of the project.
Shaping
1 weekWe write down the one thing the product must prove, then list everything not required to prove it. That list is usually longer than the brief.
Prototype and cut
1-2 weeksClickable screens go to real users. Features get cut here, and a build occasionally stops because a spreadsheet already does the job. Better learned now than in month four.
Build
6-14 weeksTwo-week slices, each one deployed and usable. You see the product working long before it is finished, which is while changing your mind is still cheap.
Launch and watch
2 weeks, then ongoingStaged release, error monitoring and the first week of real support. Then a small standing arrangement for updates and the bugs only strangers find.
Is now the right time to spend on this?
Worth reading before you brief anyone. Half the value of a cost guide is telling you not to build yet.
Worth budgeting for now if…
- People are already doing this job by hand, badly
- You can name the one thing a launch must prove
- Someone on your side can answer questions the same week
- You have actual users to show it to, not a market
Wait, if…
- The idea changes materially every time you explain it
- Nobody has spoken to a potential user yet
- A spreadsheet and a form would answer the same question
- Budget covers the build but nothing for the six months after
Frequently Asked
Questions
Common questions about scoping, cutting and phasing a first build.
Usually not the feature list. It is the number of user types the product has to serve, because each one brings its own screens, its own permissions and its own way of breaking. Payments are the second: a checkout page is quick, but refunds, failed renewals and invoices are a project of their own. The third is any integration with a system you do not control, where a sandbox key can take longer to arrive than the code takes to write.
Almost all of the admin experience. For the first months you can run refunds, account changes and content edits through a small internal tool rather than a polished back office. You can also cut settings screens, notification preferences and anything described as configurable. What you cannot cut is signup, the core flow, and knowing what users did — without usage data the launch teaches you nothing and the next quote is another guess.
Content and data. Someone has to write the onboarding copy, the empty states and the transactional emails, and someone has to clean the customer spreadsheet before it can be imported. Then there is the app store: review takes days, rejections happen for reasons unrelated to your code, and each fix needs another submission. Support is the third gap. Real users email you, and for the first months that person is usually the founder.
Running cost splits into hosting, third-party services and people. Hosting for an early product is small and stays small until traffic is real. Third-party services scale with usage: payment providers take a cut, messaging and AI models bill per call, monitoring bills per event. People is the honest one. Expect to keep a developer available a few days a month for library updates, platform deprecations and the bugs only real users find. Products without that attention rot within a year.
Phase it, in almost every case. A first release that does one job well tells you which of your assumptions were wrong, and that is information you cannot buy any other way. The exception is a product whose halves are useless apart, such as a marketplace with buyers and no sellers, or a compliance tool a regulator will not accept in part. If that is you, the right move is a narrower market rather than a bigger build.
Have a project in mind?
Fixed price after a paid discovery — no hourly billing. A real engineer reads every enquiry, and we reply within 24 hours.