The Minimum Viable Product, as classically taught, is a brilliant idea that has been quietly betraying founders for a decade. After four years of building it for clients, we are done recommending it. The replacement we have been refining since late 2020 has a different name and a different shape, and it has changed the way our studio sells engagements.
What an MVP was supposed to be
The original MVP idea was elegant: ship the smallest possible version of a product to test a single hypothesis, then iterate based on real user feedback. Eric Ries was clear that "minimum" referred to features, not quality. The architecture, the design, the engineering rigor were supposed to be appropriate. Only the feature set was supposed to be intentionally narrow.
That nuance got lost. Somewhere between the original book and the third-hand workshop slides, "minimum viable" became "build it bare-bones and fast, ship it, see what sticks." Founders treated the MVP as permission to skip foundational engineering choices. Studios obliged because clients did not want to pay for "invisible" architecture work.
What we kept seeing happen
By 2020 we had personally rebuilt three or four MVPs that had succeeded too well. The pattern was identical every time:
The MVP launched. It found a real market. Usage grew faster than the founders expected. Within six to twelve months the product hit a scaling wall: the database schema could not handle the new use cases, the auth system did not support the second user role they needed, the deployment story did not survive going from one server to three.
The studio that built the MVP then quoted a full rebuild, often at a cost two to three times the original MVP. The founders, now with revenue but also with a burning platform, had no real choice. They paid twice for the same product.
We did not want to be the studio that benefited from this pattern. We wanted to stop creating it.
What we changed
In late 2020 we drafted an internal scoping framework we called Minimum Scalable Product, or MSP. The principle was simple: features could be minimal, but architecture had to be production-grade from sprint one.
Concretely, an MSP project includes:
- A production-grade database schema. Not the simplest schema that supports the MVP feature set, but the schema that supports the next two reasonable feature additions without a migration.
- Authentication and role-based access. Even if the launch version has one user role, the auth system supports adding more without rework.
- Infrastructure ready for horizontal scaling. The launch can run on a single small instance, but moving to multiple instances behind a load balancer is a configuration change, not a rewrite.
- Real observability. Logging, error reporting, and basic metrics from day one. We do not ship something we cannot debug in production.
- Documented architectural decisions. So that the next engineer, ours or someone else's, does not have to guess why anything was built the way it was.
The feature set, by contrast, stays disciplined. We ship the smallest set of capabilities that lets users complete the core value loop. Everything else waits for real signal from real users.
What an MSP project costs
It costs more upfront than a classic MVP. We are honest about that during scoping. The architectural rigor that an MSP requires takes additional time in week one through week three, before the visible product starts taking shape.
Across the life of the product, however, an MSP costs less. We have shipped several MSP-shaped projects now where the same client came back six and twelve months later for feature additions rather than rebuilds. The compound saving is significant, and the founders' time was not consumed by a costly rebuild during the period when their attention should have been on growth.
When an MVP is still the right answer
We are not against the original MVP idea. There are cases where it remains correct.
If the goal is genuinely to test a single hypothesis and then probably throw the product away, an MVP is fine. A clickable Figma prototype, a no-code build, or a manual Wizard-of-Oz test all qualify. We will recommend these when they fit.
What we no longer recommend is shipping a real production codebase under the MVP label, with architectural shortcuts justified by "we will rebuild it later." That is the path to the burning platform.
What this changed for the studio
The scoping conversation got harder. The founders who walked in expecting an "MVP for the lowest possible cost" sometimes walked out when we explained the MSP framing. We made our peace with that.
The clients who stayed got a better outcome and continued the engagement for longer. Our average client relationship lengthened. Our portfolio got more impressive because the products we shipped survived their first wave of growth.
We are going to keep refining the MSP framework. If you are about to commission an MVP build, we would like the chance to walk you through whether MSP framing might fit your project better.