Production Readiness Checklist for Fast Builds

What does a production readiness checklist cover?

Production ready means the system can be deployed, observed and recovered by someone other than its author, and that each of those abilities has been tested rather than assumed. A production readiness checklist is a list of proofs, not intentions: each line names something you can demonstrate to a sceptical colleague today.

The checklist at a glance

Each item below names the minimum bar and the failure it prevents.

• Secrets and auth: no credentials in the repo and least-privilege roles. This prevents leaked keys and account takeover.
• Deploys: one automated path with a rollback you have used. This prevents Friday-night manual releases.
• Monitoring: uptime, error rate, latency and one paging route. This prevents customers finding the outage first.
• Backups: a restore that has been run and timed. This prevents discovering the backup is empty.
• Ownership: a named on-call person and a one-page runbook. This prevents silence during an incident.

The sections below take each item in turn, with the tests that show it is done.

Why does a rushed build fail a production readiness checklist?

A build made against a deadline usually works on the demo path and nowhere else. Secrets sit in a .env file that was once committed, deploys are an SSH session, and the only monitoring is a founder refreshing the site.

None of that is negligence. It is the correct trade when the goal is validating an idea. It becomes a problem the day real customers, real data or a real investor's due diligence arrive.

How do you fix secrets, auth, and the OWASP basics?

Move every credential out of the code, rotate anything that has ever been committed, then test authentication and access control against the OWASP Top 10. Those two steps close the most common holes in a hurried build.

Getting secrets out of the repository

Search the full git history, not only the current tree, for keys, tokens and connection strings. Anything found is compromised and must be rotated, because deleting the line does not delete the history.

Then store secrets in a managed service. AWS Secrets Manager supports rotation and fine-grained access, and other clouds offer equivalents. Give each service its own role with only the permissions it uses, so one leaked credential cannot reach everything.

Testing authentication and access control

The OWASP Top 10 is the shared baseline for web application risk, and broken access control sits at the top of it. In rushed builds the usual finding is an endpoint that checks you are logged in but not that the record is yours.

Work through these checks in order:

1. Log in as user A and note the ID of one of their records.
2. Log in as user B and request user A's record by that ID. The request must fail.
3. Repeat the request with no session at all, and with an expired token.
4. Confirm that login and password reset are rate limited.
5. Confirm that every page and API call is served over HTTPS only.
6. Check that dependencies have no known critical vulnerabilities.

A QA and testing pass can turn these into repeatable automated checks, so the same holes do not reopen with the next release.

How do you build CI/CD from scratch?

Start with one pipeline that tests, builds and deploys the main branch to a single environment, with a rollback you have used. Everything else, such as preview environments or canary releases, can follow once that path is dependable.

The minimum viable deploy pipeline setup

A usable pipeline has four stages: run tests, build an immutable artefact, deploy it, and verify a health check. GitHub Actions handles this with a single workflow file, and the same shape ports to GitLab CI or other runners.

Keep configuration out of the artefact so the same build can run in staging and production. Store the previous artefact so a rollback means redeploying a known version, not rebuilding under pressure.

The most useful test of a pipeline is a rollback performed live, not described. If nobody can redeploy the previous version in a few minutes, the pipeline is not finished, whatever the diagram says. Run that drill once with the whole team watching, and write down every step that needed a person to remember something.

What to leave out of the first pipeline

Resist the urge to build a platform. Skip multi-region deploys, custom tooling and elaborate approval chains until a real incident shows you need them.

The honest limit is that a pipeline only protects you as far as your tests go. If the suite is thin, the pipeline ships bugs faster, which is why a few end-to-end tests on the money path matter more than coverage numbers.

The same discipline applies to knowledge. If every release still depends on one person's memory, the pipeline has not removed the risk, only hidden it. Put the release steps in the repository next to the workflow file so anyone on the team can run them.

What should monitoring, alerting and paging cover?

Monitor the four signals users feel: latency, traffic, errors and saturation. Alert only on symptoms that need a human, and route each alert to a named person with a runbook.

What to measure first

Google's SRE book frames this as the four golden signals: latency, traffic, errors and saturation. For a young product, that means an external uptime check, an error tracker, request latency percentiles and database connection or disk usage.

Add structured logs with a request ID so one failing request can be followed across services. The app monitoring setup cost is mostly engineer time to wire this up plus a vendor bill that scales with log volume, so set retention limits early.

Alerts that someone will answer

An alert nobody owns is noise. Each page should say what is broken, who is on call, and link to a short runbook with the first three things to check.

Keep the paging list short. If every warning wakes someone, people mute the channel and the one real outage gets missed. Page on user-facing symptoms such as error rate or failed checkouts, and send causes like high CPU to a dashboard or a ticket.

Naming an owner and writing the runbook

The fifth checklist item is the one tools cannot supply. Name one person who is on call for each week, and a second person who takes over if the first does not acknowledge a page within a few minutes. Write the rota down where the alert itself can link to it.

The runbook can be a single page. List the components, where their logs live, how to roll back, how to restore from backup, and who to contact for each third-party service. Test it by handing it to someone who did not write the system and asking them to find the last deploy and the latest backup. Every question they ask is a gap to fill.

How do you know a backup restore actually works?

A backup counts only after you have restored it into a clean environment and timed the result. Until that has happened, treat the data as unprotected.

What to back up and how often

List what cannot be rebuilt: the primary database, uploaded files, and the configuration and secrets needed to run the app. Source code in git and artefacts in a registry can be recreated, so they rank lower.

Pick two numbers with the business. The recovery point objective is how much data you can lose, and the recovery time objective is how long you can be down. The AWS Well-Architected reliability pillar treats both as design inputs, and the backup schedule follows from them.

Proving the restore works

Restore the latest backup into an isolated environment, run the app against it, and record how long it took and what broke. Common surprises are missing encryption keys, a schema that needs a migration, and file storage that was never included.

NIST's contingency planning guide, SP 800-34 recommends testing recovery plans and capturing lessons learned. Schedule the drill, because untested restores degrade silently as the system changes.

What does hardening cost compared with an incident?

Hardening cost depends on how many checklist items your build fails, so it is scoped per project. Even so, it is a bounded, plannable piece of engineering work, while an incident is unbounded, with direct recovery costs plus lost customers and time.

Putting a number on the downside

IBM's 2025 Cost of a Data Breach report put the global average cost of a breach at $4.44 million, down from $4.88 million in its 2024 edition. That is an average across large organisations, and a startup's exposure differs, but it shows the scale on which breaches are priced. See the IBM report for the methodology.

Outages carry costs the average hides: churned customers, stalled sales and an engineering team that spends a month firefighting instead of shipping.

What drives the cost of hardening

The effort is driven by a few things you can check yourself: how many services and environments exist, whether secrets are already out of the repository, how much of the money path has automated tests, and whether any monitoring is in place. A single-service app with a managed database is a much smaller job than several services with hand-built servers.

Teams that start from a Moonship MVP usually have a short list of known shortcuts to revisit, which makes the first pass easier to scope. Whatever the starting point, ask for the scope to be written down before work begins, so you can compare the effort against the downside above.

Next step: find which items your build fails

If you are unsure which checklist items your build fails, the broken workflow assessment is a way to find out. It looks at how your current build, deploys and handovers actually work, and points to where they break, so you leave with a clearer list of what to fix first.

To talk through scope directly, use the contact form.