The word MVP has been stretched until it means almost nothing. To one founder it is a clickable prototype; to another it is a production system with billing and support. Since those differ by a factor of twenty in cost, the first useful thing any conversation can do is say which one you mean.
What the market charges
Published 2026 ranges land roughly here:
- No-code, USD 5,000 to 20,000, four to eight weeks. Real software, real users, built on tools you do not control. Excellent for testing demand.
- Lean custom, USD 30,000 to 55,000, five to eight weeks. One workflow, done properly, web only.
- Standard SaaS, USD 55,000 to 140,000, eight to fourteen weeks. Three to five features, dashboards, accounts and billing.
- AI-heavy or fintech, USD 140,000 to 300,000 and up, three to six months. Model work, compliance, or both.
One consistent finding across sources: if your plan runs beyond about four months, the scope is too large for an MVP. That is not a schedule problem, it is a definition problem.
The question that sets the price
Before scope or stack, answer this: what are you trying to learn?
If you are testing whether anyone wants this, you need the smallest thing that puts a real decision in front of a real user. No-code is often the right answer and the cheapest way to find out.
If you already have paying customers and you are testing whether it scales, you need production engineering, and no-code will become a constraint you pay to escape.
Most overspending comes from building the second when the honest answer was the first.
What actually makes an MVP expensive
- Accounts, roles and permissions. Sounds trivial, is not. Multi-tenancy decisions made early are expensive to reverse.
- Payments. Taking money brings tax, refunds, failed charges and reconciliation. It is rarely just a checkout button.
- Integrations. Each one is a dependency on something you do not control and cannot fix.
- Native mobile. Two platforms, two review processes. A responsive web app tests the idea for a fraction of it.
- AI that decides rather than suggests. A suggestion needs a model. A decision needs review workflows, audit trails and an escalation path, and most of that cost is not the model.
Cutting scope without gutting the product
Ruthless prioritisation is standard advice and useless on its own. A more practical test: for each feature, ask what you would learn if you shipped without it. If the answer is "the same thing", it is not in the first version.
The usual candidates for deferral are admin panels, which can be a spreadsheet for months; onboarding flows, which can be you on a call; and analytics dashboards, which can be a query you run yourself.
Founders often resist this because the missing pieces feel unprofessional. Early users care far less than you expect, and the pieces you build before you have users are the ones most likely to be wrong.
What to ask a development partner
- What would you cut from this scope, and why? A partner who agrees with everything is selling hours, not judgement.
- What happens if we learn the idea is wrong in week six?
- Who owns the repository, the cloud accounts and the domains? All three should be yours from day one.
- What does it cost to keep running after launch?
- Can I speak to an engineer before signing?
The first and last questions tell you the most.
Where AI genuinely changes the number
Teams using AI-assisted development report meaningful compression on well-understood work, and that is real for scaffolding, tests and boilerplate. It is much less true for the parts that decide whether the product works: what to build, what to leave out, and what the edge cases are.
So expect faster delivery on the mechanical portion, and treat quotes promising dramatic overall reductions with some care. The thinking has not got cheaper.
The short version
Decide what you are testing, then buy the cheapest thing that tests it honestly. If your timeline exceeds four months, cut scope rather than extending the plan. Own your accounts from day one. And spend on clarity before engineering, because unclear requirements cost the same whoever builds them.