Make Your MVP Ready for Paying Customers

The difference is operational, not technical

An MVP has to demonstrate that the idea works. A production system has to keep working while nobody is watching it, which is a different engineering problem with a different cost.

Nearly everything on a readiness list exists to answer one question: when this fails at three in the morning, how does anyone find out, and how bad is it by the time they do?

The readiness list

In the order that matters if you can only do some of it.

• Backups that exist and have been restored once, deliberately, as a test.
• Error tracking, so failures are known before a customer reports them.
• Access rules verified by trying to break them, not by reading the code.
• Database indexes on the queries that run most often.
• A staging environment where changes are tested first.
• Rate limiting on anything public, especially login and signup.
• A way to deploy and to roll back without the original developer.

Load is rarely the first thing to break

Founders preparing for launch usually worry about traffic. In practice the first production failures are almost never volume — they are a certificate expiring, a third-party service changing an interface, a disk filling with logs, or a scheduled job that silently stopped weeks ago.

Monitoring catches all of those. Scaling work catches none of them, and is usually premature at launch.

Decide who is on call before you need one

The uncomfortable question is who fixes it at the weekend. An MVP has an implicit answer — whoever built it, if they happen to be free — and that stops being acceptable the moment customers pay you.

This does not have to be expensive. A modest retainer with a named engineer and an agreed response time is far cheaper than the alternative, which is finding somebody unfamiliar with your system during an outage.