Every few weeks someone emails me a paragraph describing an app and asks what it will cost. The honest answer is that the paragraph is the problem. Not the budget — the paragraph. Two founders can send me near-identical descriptions of "a marketplace with payments" and one is six weeks of work while the other is six months.
So rather than quote a number and pretend it means something, here is the model I use to get to a number, what actually drives it, and where the money goes when a build overruns.
1. Why "how much does an MVP cost" has no single answer
An MVP is not a size of product. It is a question you are trying to answer with the smallest thing that answers it.
"Will restaurants pay for this?" needs a landing page, a payment link, and a human doing the work manually behind the scenes. That is two weeks.
"Can we reliably match supply and demand in real time across a city?" needs actual infrastructure, and no amount of scope-trimming makes it two weeks.
Both get called an MVP. They differ by an order of magnitude in cost. Before anyone can quote you, you have to be able to finish this sentence: "We will know this is working if happens within weeks of launch." If you cannot, you are not ready to build yet, and any quote you receive is fiction.
2. The cost model
MVP cost comes down to four multiplied terms, not a price list:
cost = build weeks × days per week × day rate + fixed costsBuild weeks is the only term you control meaningfully, and it is set by scope, not by how fast anyone types. Day rate varies enormously by geography and seniority — a London agency, a Bangalore studio, and an independent senior engineer can be 6–8x apart for the same output. Fixed costs are the ones founders forget, and I will come back to them.
The useful exercise is not comparing hourly rates. It is comparing build weeks for the same defined scope. A cheaper day rate attached to twice the weeks is not cheaper, and it usually comes with a codebase you pay to replace in year two.
Rough shape of the three tiers
From the builds I have shipped, MVPs cluster into three shapes:
Validation MVP — 2 to 4 weeks. One user type. No custom auth beyond a hosted provider. No admin panel — you use the database GUI. Payments via a hosted checkout, not a custom flow. The goal is a signal, not a product. Most founders should build this one and refuse to believe it.
Functional MVP — 6 to 10 weeks. Two user types with different permissions. Real onboarding. An admin view because support requests have started. Integrations with two or three third-party services. This is what most people picture when they say MVP.
Platform MVP — 12 to 20 weeks. Multi-tenant, or real-time, or regulated, or all three. The WiFi management platform I built for a UK operator sat here — real-time network monitoring, authentication, and analytics are not features you trim your way out of. Same for the sustainability reporting platform: once organisations depend on your numbers, "we will fix the data model later" stops being available.
Multiply your tier's week count by a day rate you have actually been quoted. That number is closer to reality than anything else you will read online.
3. The five decisions that move the number most
Auth and permissions
"Users can log in" is a weekend. "Organisations have teams, teams have roles, roles have granular permissions, and an org admin can invite people" is three weeks and a source of bugs for a year. Roles are the single most underestimated line item I see. If you can launch with one user type, launch with one user type.
Payments
A hosted Stripe or Razorpay checkout is a day or two. Subscriptions with proration, multiple currencies, tax handling, dunning, and invoice generation is weeks — and it is weeks of work that earns you nothing until you have customers to bill. Take the hosted checkout. Upgrade when the revenue justifies it.
Admin panels
Founders ask for an admin dashboard in week one and use it twice. For the first ninety days, a database GUI and a handful of scripts do the job. Build the admin panel when a non-technical teammate actually needs it, and build exactly the screens they ask for.
Real-time anything
Chat, live tracking, collaborative editing, notifications that arrive instantly. Every one of these changes your architecture rather than adding to it. If real time is the product, budget for it as the platform tier. If it is a nice-to-have, polling every thirty seconds is invisible to users and roughly free.
Mobile
"We need iOS and Android too" often doubles a quote. A responsive web app is usually the correct MVP, and React Native or Flutter is the correct second step once you know which platform your users are actually on. Cross-platform saves you the cost of two teams, but it still is not free.
4. The costs nobody puts in the quote
The development quote is usually 70–80% of what you actually spend. The rest:
- Design. If you do not have a designer, you are paying the developer to make design decisions, or you are shipping something that looks untrustworthy. Neither is free. A component library like Tailwind UI or shadcn/ui is the cheapest honest answer.
- Third-party services. Auth, email, file storage, payments, error tracking, analytics. Individually small, collectively a real monthly line. Price them before you build.
- Content. Copy, images, legal pages, a privacy policy that reflects what you actually do with data. This lands on the founder and always takes longer than expected.
- App store review. If you go native, budget one to two weeks of calendar time and at least one rejection.
- The first month after launch. Real users find things. Budget 20–30% of the original build for the six weeks after launch. This is not a contingency; it is a certainty, and the founders who plan for it ship better products than the ones who spend everything pre-launch.
5. Where builds actually overrun
Not where you would guess. In my experience it is almost never the hard technical problem — that gets attention and gets solved. It is:
Scope added quietly. "While you are in there, could it also…" Six of those is a month. The fix is not saying no; it is saying "yes, that is a week, do you want it before or after launch?" Every change should have a visible price.
Decisions waiting on the founder. I have had builds sit idle for eleven days waiting on a logo and a copy decision. Developer availability is not the bottleneck people think it is — founder availability frequently is. Block time for reviews before the build starts.
Integrations with someone else's bad API. Budget double for any integration where you do not control the other end, especially older enterprise or government systems. Their sandbox will be broken. Their docs will be wrong. This is not pessimism; it is the base rate.
Building for scale you do not have. Kubernetes for forty users. A microservice architecture for a team of one. Caching layers for traffic that has not arrived. A well-structured monolith on managed hosting will carry you to a few thousand users, and by then you will know enough to make the next decision properly.
6. How to get a quote that means something
Send this instead of a paragraph:
- The question. What will this MVP prove or disprove?
- One primary user and the single flow they complete. Write it as steps.
- The list of things you are explicitly not building in v1. This one is the most valuable and the most often skipped.
- Hard deadlines, and what they are tied to — a demo day, a funding round, a conference.
- What exists already — designs, brand, an existing codebase, accounts with services.
Any competent developer can quote that in a day, and the quote will survive contact with the work. Send a paragraph instead and you will get a number chosen to win the deal, which is a different thing entirely.
Conclusion
The number you want is not "what does an MVP cost". It is "what does this MVP cost, at a scope we have both written down, with the exclusions listed". Get to that, and the cost becomes a straightforward multiplication you can sanity-check yourself.
If you are working through this and want a second opinion on scope before committing budget — which of the three tiers you are actually in, and what can be cut without damaging the test — that is the kind of conversation I am happy to have. It is what the tech consulting and MVP development engagements exist for, and a thirty-minute call is usually enough to place you in a tier and name the three things worth cutting.