Every founder asks this question, and most answers online are either a wide range with no reasoning or a sales pitch. The honest answer is that an MVP costs whatever its scope costs. The useful part is knowing what drives that number, so you can control it before anyone writes code.
Cost is time multiplied by team
Almost every software quote comes down to two numbers: how many weeks the work takes, and how many people work on it for those weeks. A small team of two or three people for eight weeks is a very different budget from a team of six for five months. When a quote looks high or low, ask to see those two numbers. If a team cannot explain its estimate in those terms, it has not really estimated.
This also tells you where to push. You rarely save much by negotiating a day rate. You save a lot by cutting weeks, and weeks come from scope.
The five things that move the number most
- Number of user types. A product with one kind of user is far cheaper than one with students, teachers and admins, each with their own screens and permissions.
- Integrations. Payments, calendars, single sign-on, CRMs and third-party APIs each add build and testing time, and some add ongoing fees.
- Platforms. A responsive web app is one build. Native iOS and Android apps on top of a web app can come close to tripling the work.
- AI features. Calling a model API is quick. Making the output reliable, safe and affordable at scale takes longer than most founders expect.
- Compliance. Health, finance, children and education data all bring requirements that shape the architecture from the first week.
Estimate it yourself before you ask for quotes
You can get a rough number on your own in an afternoon. List every screen a user will see in your first version. For each one, write the single job it does. Then mark every integration and every user role. A simple screen with standard components is roughly a few days of work once design is settled. A screen with complex logic, real-time data or an integration behind it can be a week or more.
Add those up, then add a third on top for setup, testing, deployment and the things nobody remembers to list. The result will not be exact, but it gives you a baseline to compare quotes against. If one team quotes half of your estimate and another quotes double, both deserve questions. Our guide to scoping an MVP walks through this process in more detail.
Where founders overspend
Building for scale that does not exist yet
Your first version does not need to handle a million users. It needs to handle the first hundred well. Microservices, complex infrastructure and heavy performance work can wait until real usage tells you where the pressure is.
Polishing features nobody has validated
Custom animations, advanced settings pages and edge case handling for rare situations all cost real money. Ship the plain version, watch how people use it, then polish what matters.
Admin panels built from scratch
Internal tools for your own team rarely need custom design. Off-the-shelf admin frameworks or a simple database view can save weeks in an early build.
Costs that come after launch
The build is not the whole budget. Hosting, third-party services, model API usage, app store fees, monitoring and ongoing fixes all continue after launch. A sensible rule is to set aside money for at least three months of maintenance and small improvements, because the first real users will always find things the team did not.
Ask any team you speak to what the product will cost to run each month at a hundred users and at ten thousand users. A good team will have a clear answer.
Fixed price or time and materials
A fixed price feels safer, but it only works when scope is genuinely fixed. For most MVPs, scope changes as soon as real users arrive. A fixed quote then either becomes a change request negotiation or pushes the team to cut corners quietly. Time and materials with a clear weekly budget, regular demos and the right to stop at any point usually gives founders more control, not less.
Whichever model you choose, make sure the contract says you own the code, the accounts and the data from day one. Our list of questions to ask a development team covers this in more depth.
If you want a second opinion on a quote or a scope, send it to us. We will tell you what looks right, what looks inflated and what might be missing, even if you end up building with someone else. You can also read more about how we approach MVP development.