Every founder who asks me what an MVP costs is really asking a different question: how little can I get away with. That is a fair question, and almost nobody answers it straight, because the straight answer begins with an admission. The number is not set by a market rate. It is set by what you agree to leave out.
Before you read any range below, do one thing: write the single workflow a stranger has to complete before they would pay you, in one sentence. Every number in this post moves with that sentence.
How much does a SaaS MVP cost to build?
A SaaS MVP costs roughly €10,000 to €180,000 to build, and the tier you land in depends on what you agree to cut rather than on any market rate.
The table is my own set of planning ranges, not survey data, and the calendar times are my estimates. Public quotes disagree so widely because vendors define "finished" differently, so use the table to see the trade, not as a price list.
| Tier | Planning range | What you compromise | Calendar time (my estimate) |
|---|---|---|---|
| Scrappy | €10k–€25k | Scope: one workflow, one user role, no admin panel, manual onboarding | 4–8 weeks |
| Realistic | €40k–€90k | Timeline: multi-tenancy, billing, roles, a real admin surface | 3–4 months |
| Full | €110k–€180k | Runway: everything above plus integrations and mobile builds | 4–6 months |
Read the third column first. It is the only one that changes what you receive. The scrappy tier is not a cheaper version of the full tier; it is a different product with different things that will break. Founders who pick a tier by looking at the money column end up buying the first row and expecting the third.
If your feature list is already written down, put it through the app cost estimator before you talk to anyone. Walking into a quote with your own number, even a wrong one, turns the conversation from being told a price into comparing two estimates.
The 10k EUR MVP is real
The 10k EUR MVP is real. You pay the difference in nights and weekends, so the cost never lands on the invoice.
Agencies call it impossible because they price a team, a project manager, a QA pass and a support window. Technical founders call it obvious because they did it. Both can be right, because an invoice records money and never hours. Consider a founder who writes the code alone in the evenings: the cash bill stays small, but the hours are real, and they belong in the cost even though no ledger holds them.
Does AI make a SaaS MVP cheaper to build in 2026?
Not reliably, and a quote that bakes in an AI discount is pricing a feeling. The best controlled evidence I know of points the other way for one specific group.
METR's randomized controlled trial, published in July 2025, gave 16 experienced open-source developers 246 real issues in repositories they already knew well, and randomly allowed or forbade AI tools per issue. The developers predicted a 24% speedup. Afterwards they still believed AI had sped them up by 20%. The measurement was a 19% slowdown.
This suggests that even experienced engineers cannot feel the difference accurately enough to price it. METR itself notes the result applies to experienced developers on familiar codebases and is not evidence that AI fails to speed up other developers, and a greenfield MVP is a different setting. Read it as a caution about quotes, not as a verdict on the tools.
Where does the money go after the first version?
Most of a realistic budget pays for everything around the first working version: specification, states nobody planned for, deployment, and the weeks after real users arrive.
These durations are planning assumptions, not measurements. Discovery and specification take one to two weeks and look like the most skippable line in the estimate. They are not, because ambiguity does not disappear. It just gets discovered by a developer at a point where the decision is already load-bearing. Design runs two to three weeks for a product of this size, and its real output is not screens but the count of states nobody thought about: empty, loading, expired, declined, partially synced.
The build phase is what everyone budgets for. Deployment is where estimates slip, because it is the first time the project meets parties who do not care about your timeline: app store review, payment provider verification, environment separation, secrets handling. Then comes the phase with no name in most quotes, the weeks after launch when real users do things your test data never did.
The bill that arrives after launch
I built BookBed alone across six platforms over six months, and the expensive part was not drawing the first screens. It was stabilizing calendar behavior, bidirectional iCal sync, Stripe state, app-store releases and the edge cases that appeared after the happy path already worked. The codebase passed 66 versioned releases because production cost keeps accumulating after the demo looks finished.
One fix in that history is documented in the BookBed case study. Bookings stored at 22:00 UTC represent midnight in Zagreb, and the first date normalizer filed them under the previous day. The rewrite added timezone-aware handling and eight dedicated tests. A demo would not have shown any of it.
What do the running costs look like?
Running costs are the easy part to quote. As of 30 September 2026, Supabase lists a free plan limited to two active projects, Pro from $25 a month including $10 of compute credits, and Team from $599 a month. Stripe lists 2.9% plus 30 cents per successful domestic card transaction, with no monthly fee.
The free plan has a curfew: Supabase states that free projects are paused after one week of inactivity. That is fine for a prototype and a problem the day a paying customer can log in overnight. Plan for the Pro line from your first customer, then add your own domain, email and monitoring lines. If you want the vocabulary for these items before a vendor call, the definition of SaaS MVP cost lists the standard components.
What does a month of not shipping cost?
A month of not shipping costs one month of runway plus the feedback you did not collect during it, and founders usually discount the second part to zero.
CB Insights analysed 431 VC-backed companies that shut down since 2023 and published the breakdown in March 2026. Of the 385 with an identifiable cause, 70% ran out of capital, 43% had poor product-market fit, 29% cited bad timing and 19% had unsustainable unit economics. Companies could cite more than one reason, so the figures sum past 100%. CB Insights calls running out of capital "almost always the final cause of death, not the root problem."
This suggests that money drains while the product is still being aimed. It does not argue for shipping anything as fast as possible. It argues for shipping the narrowest thing that can be wrong in a legible way.
Here is a hypothetical with made-up numbers. Consider a team that burns €15,000 a month choosing between a €90,000 build that reaches paying users in 10 weeks and a €40,000 build that takes 30. The extra 20 weeks cost roughly €69,000 in burn, so the cheaper quote is the more expensive plan. Your numbers will differ; the method is the point. If you are weighing who does the work, I broke the vendor side down in what it costs to outsource SaaS development, and agency versus freelancer for a SaaS MVP covers the staffing trade.
How do you price your own SaaS MVP build?
Price it in a fixed order, because every step after the first is contaminated by whatever you assumed in the first.
- Write the one workflow that has to work for a stranger to pay you. One sentence, one user role, one outcome. If it takes two sentences, you have two products.
- List every state that workflow can be in, including the ugly ones: payment declined, session expired, third-party API down, data half-imported. This list predicts your tier better than the feature list does.
- Choose which row of the table you are buying and say the compromise out loud: scope, timeline or runway.
- Add a post-launch allowance before you compare quotes. As a planning assumption, start at about a quarter of the build and adjust with your own history.
- Price a month of delay in your own numbers: burn rate plus the revenue that month would have started. Compare it with the gap between tiers.
- Only now collect quotes, and give every vendor the same numbered artifact from steps 1 and 2. Quotes that answer different questions cannot be compared. If "SaaS MVP" means different things to you and your co-founder, settle that first with a plain definition of what a SaaS MVP is.
Open the document that holds your feature list and count the states, not the features. The longer that list, the more likely you are in the realistic or full tier, and the useful next move is cutting the workflow rather than collecting another quote. What number did you get?