An MVP is not a disposable prototype

“It’s just an MVP” is used to justify two completely different things, and conflating them is how a six-week launch turns into a six-month rewrite.

The first meaning is healthy: do less. The second is corrosive: do it badly. The whole craft of MVP engineering is keeping the first and refusing the second.

Minimum is about scope. Viable is about quality.

The “minimum” gives you permission to cut features. Fewer screens, fewer edge cases, fewer integrations, one platform instead of three. That’s the lever you’re supposed to pull, and you should pull it hard.

The “viable” is the part people forget. A viable product is one a real user can rely on. That means the few things it does, it does correctly, and the foundation can carry the next six months of work without being torn out.

You cut scope ruthlessly. You don’t cut quality on the scope that remains.

What we cut without hesitation

• Features. The second user type, the admin dashboard, the bulk-import tool — all of it waits until someone actually needs it.
• Polish on rare paths. The empty state can be plain text. The error message can be generic. Nobody churns over an ugly 500 page in week one.
• Premature scale. No sharding, no microservices, no multi-region. One boring server and one boring database will carry you much further than the architecture blog posts suggest.
• Configurability. Hardcode it. The settings page that lets users tweak the thing you haven’t validated is pure speculative work.

What we never cut

• Auth and access control. Getting “who can see what” wrong is a breach, not a bug. This is foundational and expensive to retrofit, so we do it properly from line one.
• The data model. Schema decisions compound harder than anything else. A sloppy schema is the thing you’re still paying interest on two years later. We take the time here.
• Migrations from day one. Even the MVP gets versioned, checked-in migrations. “We’ll add migrations later” means “we’ll be afraid of our own database later.”
• A path to observability. Not a full dashboard, but structured logs and the ability to answer “what happened to this user’s request.” When the MVP gets traction, you need to see it working.
• Backups you’ve actually restored. A backup you’ve never tested is a hope, not a backup.

The test: would a rewrite be cheap or catastrophic?

Here’s the honest way to tell a healthy MVP from a disposable one. Imagine you have to significantly change direction in three months.

In a healthy MVP, the data model holds, auth holds, the deploy pipeline holds — you change the product surface and keep the foundation. In a disposable prototype, the foundation is the thing you have to throw away, because it was never built to carry weight.

Speed comes from cutting scope. It does not come from skipping foundations — that just moves the cost downstream and adds interest.

---

So when someone says “it’s just an MVP,” the right follow-up is: which kind? The kind where we ship less, or the kind where we’ll be rewriting this by autumn? We only build the first kind.