The MVP works. Why it won't survive real users.

An MVP is a proof, not a foundation

A minimum viable product has exactly one job: prove that the idea is worth building properly. To do that job quickly, good MVPs deliberately skip things — and the things they skip are, almost by definition, the things that don't matter until you have real users. Which is why the MVP works right up until you have real users.

What gets skipped — and why it matters later

• Authentication and permissions. A prototype often has one kind of user and trusts everyone. Real products have roles, boundaries, and data one user must never see from another. Retrofitting that after the fact touches every query in the system.
• The data model. Early on, a loose schema is a feature — it lets you move. At scale, the shortcuts (the JSON blob standing in for a real relationship, the missing index, the status field with no constraints) become the thing that makes every new feature harder and every report slower.
• Background and scheduled work. In a demo, everything runs inline on the request. In production, the email, the export, the third-party sync, and the heavy report belong in a queue — or they'll time out the moment more than a few people use them at once.
• Error handling and observability. A prototype fails by showing you a stack trace. A product has to fail safely, retry what's transient, and tell you what broke before a customer does.

The prototype didn't lie to you. It answered the question it was built to answer — and that question was never "will this survive production?"

You don't have to start over

The expensive mistake is to conclude that because the MVP won't scale, it must be thrown away and rewritten from zero. Usually it doesn't. The idea is validated, the surface is understood, and much of the code is fine. What's needed is to find the parts that break first under real use — the auth model, the hot queries, the inline work that should be queued — and rebuild those, deliberately, while leaving the rest.

How to sequence the rebuild

• Start where it will break first, not where it's easiest. Usually that's the data model and auth, because everything else depends on them.
• Make the boring parts boring: real permissions, a schema with constraints, a queue for anything slow, and errors that fail safely.
• Keep the validated product behaviour intact. Users shouldn't feel the rebuild — they should just feel the app stop falling over.

The MVP did its job. The next job is different: take the thing that proved the idea and give it a foundation that survives the people who liked it. That's not a failure of the prototype. It's the point of one.