Type "MVP cost" into a search bar and a row of agencies will quote you the same thing: ten thousand dollars, six weeks, and a working SaaS product at the end of it. The number is theater. It buys you a clickable shell — a landing page, a login, a dashboard with fake data — that does none of the things a SaaS product has to do to take a stranger's money every month. The pitch survives because it tells founders what they want to hear, which is that "minimum viable" means "cheap and fast." For SaaS specifically, it means almost the opposite, and the gap between those two readings is where most of these products quietly die.
The word everyone repeats and nobody finished reading
The MVP was never meant to be a budget tier. Eric Ries defined it as the version of a product that lets a team collect the maximum amount of validated learning for the least effort — "learning" being the operative word, not "product." Somewhere between the book and the sales deck, the definition got amputated. "Maximum validated learning" fell off. "Least effort" stayed. What's left is a license to ship something half-built and call the corner-cutting a methodology.
Reid Hoffman's line — if you're not embarrassed by your first release you shipped too late — is the most abused sentence in software. It was about polish and scope: don't gold-plate the edges. It is now quoted to excuse a broken core. There is a difference between an embarrassing onboarding flow and a billing system that double-charges, and SaaS founders keep being sold the second in the language of the first.
"Minimum" ate "viable," and SaaS is where the bill comes due
The weekend MVP works fine for some things. A two-sided marketplace can test demand with a landing page and a Stripe button wired to a human doing the matching by hand. A consumer app idea can be validated with a Figma prototype and an ad budget. Those are genuinely minimum, genuinely viable, because "viable" there only means "enough to learn whether anyone wants this."
SaaS is a different animal because of what you're actually asking for. You are asking a stranger to enter a credit card for a recurring charge, hand you their customers' or their company's data, and trust that the thing will be up tomorrow. None of that is optional, and none of it is the fun part. Real authentication, real billing and subscription logic, multi-tenancy that keeps one customer's data away from another's, a security posture that won't leak, and uptime that doesn't evaporate on a Tuesday — that is the floor of "viable" for SaaS. A to-do demo isn't viable. A thing holding someone's payroll, patients, or pipeline is, and you cannot fake your way to it over a weekend.
This is why the most-cited startup post-mortem — roughly a third to forty percent of failures attributed to building something nobody needed — gets misread too. Founders take it as license to ship anything fast and let the market sort it out. But "no market need" is rarely discovered by a broken product; a broken product just teaches you that your product was broken. You learn whether the need is real only when the thing works well enough that someone's willingness to pay is a verdict on the idea and not on your bug count.
The lie that you'll throw it away
The quiet assumption underneath "cheap MVP" is that it's disposable — a probe you fire, learn from, and rewrite properly once the money arrives. In eleven years of building software, I have watched that rewrite happen almost never. The MVP is not the prototype. The MVP is version one of production, and the shortcuts you took to ship it in six weeks become the foundation every later feature is bolted onto. The "we'll fix it after we raise" code is still running after the Series A, because by then there are paying customers on top of it and nobody can afford the downtime to gut the basement.
We picked up Nautical Commerce as a one-year-old codebase and delivered against a 90-day go-live for a marketplace-as-a-service platform. The platform we built has since processed 200,000-plus transactions a month and met SOC 2 — none of which is reachable if the first version was assembled to be discarded. The early decisions about data model, tenancy, and billing don't get a do-over; they get inherited. That is the real cost of the cheap MVP, and it doesn't appear on the invoice. It appears eighteen months later as the reason a two-day feature takes three weeks.
Minimum is the expensive part, not the cheap one
Here is the inversion the conventional take misses: the hard, valuable discipline isn't building fast. It's cutting. Finding the genuinely smallest thing that is still viable — that a stranger will pay for and trust — is harder than building the bloated version, because it requires the judgment to know which of the forty things the founder "needs" are actually two things, and the spine to say so.
We took on Meal4U as a rescue after a prior team failed to deliver. The first week was not coding. It was scope deconstruction: re-estimating the build something like ten times, cutting thirty to fifty percent of it each pass, until what remained was the smallest product that could actually ship. That is what "minimum" should mean — a deliberate, painful subtraction down to the load-bearing core — not the first thing a junior could throw together by Friday. The agencies quoting you a weekend aren't doing that subtraction. They're doing the addition that's easy to bill.
What "viable" actually costs
A real SaaS MVP — the kind with working billing, tenancy, security, and enough reliability to charge for — lands roughly in the $40,000 to $100,000 range, with the spread driven by how much of that floor you need on day one and how much regulated data you touch. A four-person team runs about $25,000 to $55,000 a month, and a viable SaaS first version is a few of those months, not a few of those days. If a number is dramatically below that band, you are not being sold a cheaper MVP. You are being sold a smaller fraction of the work, with the missing parts deferred to the version you'll pay for twice.
None of this means slow. We built MyFlyRight from scratch on React, Laravel, and PostgreSQL — and the platform we built has since processed over a million compensation claims and recovered €100M-plus for passengers, across a partnership now in its tenth year. The first version was small. It was also built to survive being version one of a decade-long product, which is the only kind of small that's worth shipping in this category.
Build it like you'll keep it, because you will
If the MVP is going to become production — and it is — then the corner you cannot cut is the one nobody sees: the quality of the thing underneath. At our studio every pull request is reviewed by at least one other senior engineer before it merges, and that is not bureaucracy. It is the cheapest insurance against the specific failure mode of the cheap MVP, where speed is bought with sloppiness and the sloppiness compounds into a rewrite. "Move fast and break things" is a fine slogan for a feature flag. It is a terrible one for the schema your customers' money lives in.
This is why we say we're not an MVP factory. The factory model — pump out a cheap v1, hand it back, never see it again — works for the factory and almost never for the founder, because the founder is the one who inherits the basement. The teams that win treat the first version as the start of something they'll maintain, not a brochure they'll discard.
The position, stated plainly
The SaaS MVP is not the cheapest, riskiest version of your product. It is the smallest version a stranger will pay for monthly and trust with their data — and it is the codebase you will live inside for years, so build it like you mean to keep it. Spend the discipline on subtraction, not on corner-cutting. The founders who internalize that ship slower than the weekend-MVP pitch promises and faster than the bloated everything-build, and they're the ones still standing when the rewrite that was supposed to fix it all never comes. The cheap MVP isn't cheap. It's a loan, and the interest is the eighteen months you spend paying down a foundation you should have poured once.
Last updated July 17, 2026