The Production Readiness Checklist

"Production ready" gets used as though it were a quality score, which is why nobody agrees on whether something is. It isn't a score. It's a set of promises to specific people:

• To your customers: their data is safe, it works, and it will still work tomorrow.
• To whoever is on call: they'll find out before the customer does, and they'll have enough information to fix it.
• To your future self: you can change this without holding your breath.

Every item below exists to keep one of those promises. Which means you can also decide, deliberately, not to keep some of them yet.

Scale it to the stakes

A weekend project and a payroll system don't need the same checklist, and pretending otherwise is why these lists get ignored. Three honest tiers:

• Tier 1 — you have real users. Everything under Data and Security below. Non-negotiable, whatever the product.
• Tier 2 — people rely on it for work. Add Reliability and Operations.
• Tier 3 — you hold money, health, or regulated data. Add everything, and get an external review.

Below Tier 1 there is no such thing as production ready. Above it, skipping items is a decision, not an oversight — write down which ones and why.

Data — the promises you can't unbreak

Everything else is recoverable. This isn't.

• Automated backups, running on a schedule, retained long enough to survive a problem you notice late.
• A restore you have actually performed. An untested backup is a hope. Do it once, time it, write down the steps.
• Migrations as versioned code, applied identically to every environment. Schema changes made by hand in a database UI are how environments silently diverge.
• A tested rollback path for the last deploy, including what happens to data written by the version you're rolling back.
• Point-in-time recovery if you can afford it. "Restore to last night" loses a day.

Security — the ones that end companies

Ordered by how much damage each prevents.

• An ownership check on every endpoint that takes a record ID. The most common serious flaw in software generally, and near-universal in generated code.
• No secrets in the client bundle. Anything ever exposed there is compromised and must be rotated, not moved.
• Rate limiting on login, password reset, signup, and expensive endpoints.
• Dependency audit in CI, so a known vulnerability fails the build rather than waiting for someone to notice.
• Security headers and HTTPS everywhere, with HSTS.
• Failure closes. When an authorization check errors, the request is denied. Read the catch blocks and confirm.
• Admin surfaces behind real access control, not an unguessable URL.

Reliability and operations — the 3am test

One question covers most of this: if this breaks at 3am, how do you find out, who responds, and do they have what they need?

• Error tracking capturing exceptions with enough context to debug.
• Uptime monitoring on the critical paths — not just the homepage. Checkout being broken while the marketing page loads is the failure mode that costs money.
• Alerting somewhere a human will actually see it. An alert into an unread channel is not monitoring.
• Structured, searchable logs with request identifiers, retained long enough to investigate something reported a week later.
• A named owner. The most-skipped item on any list like this, and the one that makes the rest work.
• Health checks your platform can act on.
• Slow work moved to background jobs, so a third-party outage doesn't take your signup flow with it.

Performance — where it becomes revenue

• Indexes on every column you filter or join on, and N+1 queries eliminated.
• A connection pooler between app and database, especially on serverless.
• Core Web Vitals passing at the 75th percentile — measured on field data, not a lab score.
• A load test at a plausible peak, so you learn the ceiling before your best traffic day does.

The legal and unglamorous

Genuinely easy to forget, genuinely bad to miss.

• Privacy policy and terms, especially taking payments or serving the EU.
• Cookie consent where required, implemented so it doesn't wreck your layout metrics.
• Email deliverability configured — SPF, DKIM, DMARC — so password resets don't land in spam.
• Account deletion, if you have accounts. Increasingly required, and slow to retrofit.
• Analytics, so you learn something from the traffic you worked for.
• A tested billing flow including the failures: declined cards, cancellations, refunds, dunning.

Launch mechanics

• Deploy from a branch, not from someone's laptop.
• A staging environment that resembles production closely enough to be informative.
• A documented rollback, practised at least once.
• A soft launch or gradual rollout where the product allows it.
• Someone available for the first few days who can actually fix things.

How to use this

Don't work top to bottom. Work Data, then Security, then the 3am test — those three cover the failures that are unrecoverable, company-ending, or invisible. The rest can be scheduled.

Then write down what you consciously skipped. A checklist's value isn't the ticks; it's the short list of things you decided to live without, so nobody is surprised later.

If you'd rather have someone go through this against your actual system and tell you honestly where you stand, that's work we do. See how we approach SaaS development, or send us the repo.