The Production Readiness Checklist

Engineering checklists are older than most of today's tools. Joel Spolsky's "Joel Test" (2000) asked twelve yes-or-no questions, such as "Can you make a build in one step?" and "Do you have a bug database?", and argued that a team scoring below ten had serious problems. The Twelve-Factor App (2011) wrote down how Heroku-era services should handle config, logs and processes. Google's SRE (site reliability engineering) teams run a formal PRR (production readiness review) before they take on a service, described in the SRE book (2016), and AWS publishes its Well-Architected Framework (2015) as a set of review questions. Investors and enterprise buyers run the same exercise under other names: technical due diligence and the security questionnaire.

You have met the result whenever a new project felt easy to join: one command to run it locally, a README that was true, a failing test before a broken deploy, and an error report with the exact line before the first support ticket. The opposite is just as recognisable. The smallest possible version of the checklist is a file in the repository that the team actually keeps up to date:

Missing items rarely hurt on the day they are skipped. They surface later and all at once: during an incident when nobody can tell which release broke checkout, during a due-diligence call when there is no answer to "how do you restore the database?", or when the first enterprise prospect sends a 200-question security questionnaire. Each gap makes every future change a little slower and a little riskier, which is what "technical debt" means in practice. The goal is not to tick every box on day one; it is to know which boxes are empty, why, and when that becomes unacceptable.

The items group into eight areas. Each area answers one question about the app; if you cannot answer it, the corresponding items are missing. The diagram uses PR for pull request and SLO for service level objective.

Write down the domain before the code spreads it around. A glossary that says what a "workspace", a "member" and a "seat" are, how they relate and which states each can be in keeps the database, the API, the UI copy and the analytics events using one name per concept. Without it the same thing ends up as team in the schema, "organisation" in the UI and account in billing, and every feature pays a translation tax. Schema changes go through versioned migrations reviewed like code, and backups only count once a restore has actually been tested against an RPO and RTO you have written down.

The main branch is always deployable, every pull request runs lint, type checks and tests in CI (continuous integration), deploys are automated and rollback is a single action. Feature flags decouple deploying code from releasing a feature: unfinished work ships dark, a risky change rolls out to 5% first, and a misbehaving feature is turned off in seconds instead of reverted in minutes. Every flag needs an owner and a removal date, or the codebase fills with branches nobody dares to delete. A changelog records what changed for users, and short ADRs record why the big technical choices were made, so the next person does not have to rediscover them.

A new engineer should get a working app with realistic seed data from a clean machine with one documented command, and a .env.example should list every variable. Development, staging and production use separate data and separate credentials, and staging is close enough to production that a green staging deploy means something. Tests concentrate on what breaks expensively: unit tests for business rules, integration tests against a real database for queries and permissions, and a handful of end-to-end tests for the critical paths such as sign-up, payment and the core action, often called E2E tests. Coverage is a useful map of what is untested on those paths; as a company-wide target it rewards tests that assert nothing.

Errors reach an error tracker with the release version, stack trace and the user or tenant affected, and someone is alerted on new or spiking errors, so the team hears about breakage before customers do. Logs are structured and carry a request ID; metrics and SLOs (service level objectives) cover the user-facing paths. Product analytics events use the names from the domain glossary. Authorization is checked in one place on the server, secrets live in a secret manager, dependencies are scanned and updated automatically, and personal data can be exported and deleted on request. Health checks, graceful shutdown, timeouts and idempotent retries keep failures small; runbooks and blameless postmortems make each one less likely to repeat.

The same practice has a different "done" at different sizes. Early on the risk is building the wrong thing slowly, so anything that slows iteration without preventing a likely disaster can wait. At mid-size the risk shifts to breaking things that paying customers depend on. At enterprise scale it is regulatory, contractual and organisational: many teams, audits and customers who negotiate your uptime. In the table, MFA is multi-factor authentication, a11y is accessibility, SOC 2 and ISO 27001 are the two common security certifications enterprise buyers ask for, and SIEM (security information and event management) is the system a security team uses to collect and correlate logs.

Selling to businesses and selling to consumers stress different parts of the same checklist. B2B (business-to-business) customers are few, large, contractual and demanding about control and proof. B2C (business-to-consumer) users are many, anonymous and impatient, so scale, onboarding and privacy dominate. Below, SSO is single sign-on, usually over SAML (Security Assertion Markup Language) or OIDC (OpenID Connect); SCIM (System for Cross-domain Identity Management) lets a customer's identity provider create and remove accounts automatically; an SLA is a service level agreement; a DPA is a data processing agreement; GDPR and CCPA are the EU and California privacy laws.

A checklist only helps if it produces decisions. The review below fits in an hour for a small product and works the same way for a single service in a large company.