"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.
Frequently asked questions
What does production-ready actually mean?
Production-ready is not a feeling, it is a checklist — it means the system behaves predictably on the bad day, not just the good one: when a dependency times out, a deploy goes wrong at 2am, traffic spikes 10x, or a malformed payload arrives. An MVP optimizes for the happy path, while production-readiness is entirely about the unhappy ones. The bar is defined through seven gates covering observability, error handling, deploys and rollback, security, data safety, performance under load, and on-call runbooks.
What is the checklist for production-ready software?
There are seven gates: observability (structured logs, metrics, and traces wired up before launch, so you can answer 'is it down and why' in under five minutes), error handling and recovery (every external call has a timeout, retry policy, and defined failure behaviour), automated deploys and rollback (one-command deploy and rollback with a CI pipeline that blocks broken builds), a security baseline (secrets in a manager, scanned dependencies, server-side auth, least-privilege IAM), data safety (restore-tested backups and reversible migrations), performance under load (a load test proving the system holds at projected peak), and on-call with runbooks. A system that carries real users or money should clear all seven before it ships.
Why aren't most MVPs production-ready?
MVPs are built to validate a hypothesis quickly, so they deliberately trade away production properties — that is the point — but the danger is forgetting the debt was taken on. The recurring failure pattern is an MVP that gets traction, a team that bolts on features instead of hardening, and twelve months later 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.
Related reading
Event-Driven Architecture: Queues, Streams, and When Async Actually Helps
When to reach for queues and event streams instead of synchronous calls — the difference between a queue and a log, the patterns that make async reliable (outbox, idempotency, dead-letter queues), and the failure modes teams underestimate.
EngineeringAPI Design and Versioning: Building Interfaces You Won't Regret
How to design APIs that survive contact with real integrators — resource modeling, consistency, pagination, and a versioning and deprecation strategy that lets you evolve without breaking every customer.
EngineeringPlatform Engineering: Building an Internal Developer Platform That Pays Off
What platform engineering and internal developer platforms actually solve for growth-stage SaaS — golden paths, self-service, and paved roads — and how to build one without creating a bottleneck team.