What "Production-Ready" Actually Means (and Why Most MVPs Aren't) 
 

"It works on my machine" and "it's in production" are separated by a gap that sinks more growth-stage companies than any missing feature. An MVP that demos beautifully can still be nowhere near production-ready — and the difference is rarely visible in the UI. Production-ready is not a feeling; it is a checklist. Here is the bar we hold our own work to, and the one we recommend any CTO adopt before telling the board a system is done.

Production-ready is about the bad day, not the good one

Any competent developer can build software that works when the database is up, the network is fast, the input is well-formed, and one user is clicking. Production-ready means the system behaves predictably when none of that is true — when a dependency times out, a deploy goes wrong at 2am, traffic spikes 10x, or a malformed payload arrives. The MVP optimizes for the happy path. Production-readiness is entirely about the unhappy ones.

The seven gates

• Observability: structured logs, metrics, and traces wired up before launch — not after the first incident. If you cannot answer 'is it down, and why' in under five minutes, it is not ready.
• Error handling and recovery: every external call has a timeout, a retry policy, and a defined behaviour on failure. No unhandled promise rejections, no silent catches.
• Automated deploys and rollback: one-command deploy, one-command rollback, and a CI pipeline that blocks broken builds. Manual SSH-and-pull is not a deploy strategy.
• Security baseline: secrets in a manager not the repo, dependencies scanned, auth enforced server-side, and least-privilege IAM. The MVP shortcuts here become the breach later.
• Data safety: automated backups that are actually restore-tested, migrations that are reversible, and no destructive operation without a guardrail.
• Performance under load: a load test that proves the system holds at projected peak, plus defined autoscaling or capacity headroom.
• On-call and runbooks: someone owns production, alerts route to a human, and the three most likely failures have written runbooks.

Why most MVPs aren't (and that's sometimes fine)

MVPs are built to validate a hypothesis quickly, so they trade away exactly these properties — that is the point. The danger is forgetting the debt was taken on. The failure pattern we see repeatedly: an MVP gets traction, the team bolts on features instead of hardening, and twelve months later they have a revenue-bearing system with no backups, no rollback, and one person who understands the deploy. The fix is cheap at month two and brutal at month eighteen.

The 'definition of done' that prevents this

Add a production-readiness checklist to your definition of done and make it a release gate, not an aspiration. Before a system carries real users or money, it clears the seven gates above — or leadership signs off explicitly on which ones it is deferring and why. The act of writing down 'we are shipping without restore-tested backups' is usually enough to stop someone from doing it.

How Infiniti Tech Partners approaches this

We treat production-readiness as a first-class deliverable, not a phase that gets cut when the timeline slips. New systems ship with observability, CI/CD, backups, and runbooks from day one; when we inherit an MVP that outgrew its foundations, we run a readiness review against this checklist and hand back a prioritized hardening plan with the risk of each gap spelled out. If you have a system carrying real users that has never had a readiness review, that is the place to start a conversation.