Production-Ready Software Checklist

Production-Ready Software Checklist

Production-ready software is software that survives real users, partial failure, malicious input, and absent engineers. The checklist below is the floor we apply on every production-readiness hardening engagement. If a system cannot truthfully tick every item, it is not production ready, regardless of how polished the UI looks.

The short answer

Production readiness is not a feeling, it is a list. Every item below has a binary answer. Anything that cannot be answered yes today is a known risk, and a known risk is something a team can plan around. Unknown risks are what take systems down.

Authentication and authorization

• Every protected route checks identity on the server, not only on the client.
• Every protected route also checks authorization, not just authentication.
• Roles and permissions live in a dedicated table, not on the user record or in client storage.
• Session tokens have an expiry and a documented refresh policy.
• Password reset and email change flows require re-authentication.
• Service-to-service calls use scoped credentials, not shared admin keys.

Input handling

• Every input is validated on the server, regardless of UI validation.
• Validation errors return structured responses, not stack traces.
• Untrusted input is never concatenated into SQL, shell, or HTML.
• File uploads have a size limit, a type allow-list, and a virus or content scan if user-facing.

Data integrity

• Every write is either idempotent or guarded by a uniqueness constraint.
• Multi-step writes run inside transactions with a documented isolation level.
• Foreign keys are enforced at the database level, not only in application code.
• Soft deletes and hard deletes are distinguished and documented.
• Backups run on a schedule, are encrypted, and have been restored at least once.

External calls

• Every outbound call has a timeout.
• Every outbound call has a retry policy with backoff.
• Circuit breakers or equivalent protect against cascading failures.
• Third-party credentials live in a secret store, not in the repo or the build.
• Webhook receivers verify signatures and are idempotent.

Errors and observability

• Errors are logged with request id, user id, and route.
• Logs are structured, not free text.
• Critical paths have metrics tied to alerts.
• Alerts page a human, not a shared inbox.
• A single dashboard answers "is the app healthy right now" without interpretation.
• A runbook exists for every alert.

Build and deploy

• The build is reproducible from a clean checkout.
• Dependencies are pinned with a committed lockfile.
• Database migrations are run by a script, not by hand.
• A single command builds, migrates, and deploys.
• Rollback is documented and has been tested.
• Secrets are loaded from a secret store at runtime, not baked into artifacts.

This is the CI/CD and test coverage baseline.

Tests

• The boundaries of the system are covered by tests: auth, payments, third-party APIs, the public API surface.
• Critical business rules have unit tests with documented edge cases.
• Tests run on every pull request and block merge on failure.
• Flaky tests are quarantined within a week or deleted.
• A failing test in main blocks deploys.

Security baseline

• Dependencies are scanned weekly and patched on a documented cadence.
• Secrets are rotated on a schedule.
• HTTPS is enforced everywhere, including internal traffic where feasible.
• Security headers (CSP, HSTS, X-Content-Type-Options) are set.
• Admin actions are logged with actor, target, and timestamp.
• A documented incident response plan names humans, not roles.

People and process

• More than one person can deploy.
• More than one person can access production data, with audit logging.
• On-call rotation is documented and rotates on a schedule.
• Postmortems happen within a week of a customer-impacting incident and are written down.
• A change log exists and is updated on every release.

What this checklist is not

It is not exhaustive. It is the floor. Above it sits everything that depends on your domain: regulated data, multi-tenant isolation, contractual SLAs, federal accreditation. Below it is not "minimum viable," it is "demo." A system that does not meet the floor is a system that will surprise you.

How to use it

Walk the checklist with the team that owns the system. For every item, the answer is yes, no, or "we do not know." The "we do not know" answers are usually the most expensive. They become the first work items.

If the list is mostly red, that is what a codebase review is for: it produces a prioritized plan to get to green without rewriting the application. If the system was AI-built and is breaking in production, the same checklist applies. The path to green is the make-ai-generated-software-production-ready sequence.