What changes when an MVP becomes a real product

The transition is operational, not architectural

Teams expect the move to production to be a rewrite. Usually it is not. The code that handled ten users handles a few hundred without much complaint. What changes is that an outage now has a cost, and somebody has to notice it before a customer does.

What to have in place

Backups you have restored. An untested backup is a belief, not a backup. Restore one to a scratch environment and time how long it takes.

Alerting on symptoms, not just crashes. The failures that matter are usually not a process dying. They are a queue growing, a success rate slipping, or a job that silently stopped running.

A way to deploy without downtime, and to roll back. The second half matters more than the first on the day you need it.

Somebody who is responsible. Not a rota for its own sake, but a clear answer to who looks when something breaks at an inconvenient hour.

What usually does need rework

Rate limiting, idempotency on anything that charges money, and access control if the MVP assumed a single trusted user. These three appear on almost every list.

Do it before the launch that matters

Every one of these is cheaper to add during a quiet week than during the incident that proves you needed it.