What a Good MVP Actually Is (And What It's Definitely Not)

"MVP" is one of the most abused terms in software. It's been used to justify shipping broken products, to excuse missing features that users actually need, and to describe prototypes that were never meant to be used in production. None of these are what it means.

Getting the MVP definition wrong is expensive. If you build too little, you can't prove anything. If you build too much, you've spent months on things that might not matter. The difference between those two outcomes is in how clearly you've defined what you're trying to prove.

What Minimum Viable Product Actually Means

The key word is "viable" — not "minimal." An MVP is the smallest version of your product that can prove your core business hypothesis. Viable means it works. It means a real user can accomplish the primary job they hired your product to do. It means you can put it in front of a paying customer without apologizing for what's missing.

The minimum refers to scope, not quality. A well-built, production-grade system that does one thing is a better MVP than a sprawling prototype that does ten things poorly.

An MVP is not a half-built product. It's a fully-built product with a deliberately narrow scope.

The Real Goal: Prove the Business Model

Before you define the scope of your MVP, you need to define what you're trying to prove. This should be a specific hypothesis:

• "K-12 school districts will pay $X/year for a system that digitizes their maintenance workflows."
• "Small restaurants will use our reservation tool if it takes less than 10 minutes to set up."
• "Field service companies will route and dispatch their technicians through our app instead of phone calls."

Your MVP needs to be complete enough to test that hypothesis. Nothing more. If your hypothesis is about getting a first paying customer, the MVP needs to be good enough to charge for. If your hypothesis is about workflow adoption, the MVP needs to cover the core workflow completely.

The Scope Trap

The most common mistake in MVP scoping is letting a complete vision leak into the initial build. You know what the product will eventually be, and you keep adding things "because they'll be important later." This is how a 90-day build becomes an 18-month one.

The discipline required is ruthless: for every feature on your list, ask whether it's required to prove the hypothesis. If the answer is no — not helpful, not relevant to your current hypothesis — it goes in the backlog. Full stop.

What You Cannot Cut

Some things are non-negotiable even in an MVP:

• Security. A multi-tenant SaaS that leaks one customer's data to another is not an MVP — it's a liability.
• The core workflow. If your product solves a specific problem, it needs to solve that problem completely. An MVP that almost solves the problem isn't viable.
• Reliability. A system that loses data or goes down regularly won't get honest feedback — it'll just get abandoned.
• Payment if you're charging. If you're testing willingness to pay, you need to actually be able to accept payment.

What We Cut in OpsFlow's MVP

When we shipped OpsFlow to the first school district, we cut: advanced analytics and reporting dashboards, a full inventory management module, multi-district consolidation views, the vendor/contractor portal, and calendar integrations.

What we kept: work order creation and assignment, real-time status updates via SignalR, the mobile app for field technicians, role-based permissions, and basic billing. That was enough to prove that districts would pay for it and use it daily.

Everything we cut eventually got built — but only after we knew the core was working. The discipline of cutting it initially is what made the core good.