The MVP Dysfunction

Over my career working with tech startups, the term “MVP” has been used so loosely that it has lost most of its foundational meaning.

Originally, a minimal viable product was a disciplined way to learn. You shipped the smallest thing that delivered real value, watched how users behaved, and iterated based on evidence. It was intentionally designed, highly constrained, and ruthlessly focused.

That is not how the term is used anymore.

Today, MVP is routinely used to justify poorly thought out products, vague requirements, and rushed execution. It has become a convenient label for work that is underdesigned, under-resourced, and pushed onto product engineering teams with the expectation that they will somehow make lemonade. 🍋

From Inspiration to Exploitation

The original idea behind an MVP was actually pretty simple. Create just enough value(or even perceived value) to early adopters and generate meaningful feedback. Learn quickly. Adjust deliberately.

The problem probably started “just enough”

Once MVP became open to interpretation, it turned into a catch-all excuse for cutting corners. Leadership began using it to push teams to ship faster and cheaper, without investing the time needed to define the problem, validate assumptions, or design the system properly.

The process stopped being lean and started being lazy.

Consider a Typical Scenario

Business leaders push for a new product idea and quickly assemble a team that is, more often than not, incomplete. There is no experienced product manager. No designer. Sometimes not even a technical lead.

Instead, the team consists of junior developers and low-cost overseas contractors.

They are handed a list of “requirements” that are not requirements at all. They are feature names. No context. No user stories. No constraints. No definition of success or done.

This is what I call title-driven development, and it is where things start to fall apart.

The MVP Cycle

Here is how it usually plays out.

Initial excitement
Business leaders convince themselves they are building something revolutionary and immediately start selling it. The target market is vague, often defined as “anyone who might pay for it.” Enterprise-grade promises are made long before the first real decision has been made.

Reactive development
The product team scrambles to keep up. Each new customer introduces a new set of feature requests. Instead of validating assumptions or refining the product, leadership pushes to add more titles to the roadmap. More features equals more value. At least on paper.

System breakdown
Within months, the cracks in the foundations start to show. Performance issues surface. Security testing reveal frightening results. The codebase becomes fragile and hard to reason about. The product team raises concerns, but leadership shrugs it off as normal MVP growing pains.

The inevitable audit
A year later, a third party is brought in to “take a look.” The verdict is predictable. The product is technically minimal, barely viable, and full of shortcuts. The recommendation is a full rewrite. The original team is quietly blamed, replaced, and forgotten.

Then the cycle usually starts again.

Beyond MVP: Architecture Actually Matters

When I build, I do not buy into this pattern. Architecture is not something you tack on later. It is not an optimization phase. It is the foundation.

Good architecture requires intent. It requires someone to think past the next demo and ask how this system should behave when it has real users, real data, and real consequences.

Setting Yourself Up to Not Rewrite Everything

Some companies avoid this trap by doing a little more work up front. Not months of overdesign. Just enough to avoid obvious future pain.

Take multi-tenant architecture as a simple example. It is rarely “free,” but it is also rarely expensive if done early. Compare that to trying to retrofit it after customers are onboarded and data models are locked in. One of those options is mildly inconvenient. The other is brutal and expensive.

This is the difference when you intentionally design.

Architecture Is Also About People

None of this works if you only focus on code.

Teams are systems too. Communication paths matter. Decision making matters. Clear ownership matters. When those things are missing, technical problems multiply fast.

Strong products come from teams that are structured to collaborate effectively. That means product, design, and engineering working together with shared context and clear goals. Not throwing work over the wall and hoping for the best.

When business leaders invest in both technical structure and social structure, teams can move quickly without breaking everything they touch.

Maybe, Stop Calling It An MVP?

This is not a new idea. It has been exhaustively covered in many different books.

What is new is how badly the term MVP has been abused.

It has become a shield for poor planning, weak requirements, and avoidable technical debt. It gives cover to rushed decisions and under-resourced teams.

It is time to retire the term, or at least stop using it as an excuse.

A better approach is straightforward. Define the problem clearly. Design the system intentionally. Build the team thoughtfully.

Do that, and you can ship quickly without setting yourself up for failure.
Do not, and you will just be planning your rewrite a little earlier than expected.