Running a Production Readiness Review: Checklists, Architecture Audits, and Launch Gates for Engineering Teams

Before any system goes to production, someone needs to answer a deceptively hard question: is this actually ready? Not “is the feature complete?” Not “did all the tests pass?” But: if this serves real traffic at 2am on a Saturday, and something breaks, can your team respond, diagnose, and recover without it becoming a five-alarm incident?

Most teams skip the structured version of this question. They ship when the demo works and the QA sign-off is in. That is fine until it is not.

The production readiness review (PRR) is the process of systematically answering that question before it gets answered for you by an outage. It is not a gate designed to slow teams down. It is a forcing function that surfaces gaps while you can still fix them cheaply.

This article covers how to run one: what to check, how to score findings, who should participate, when to gate versus approve with conditions, and how to build a repeatable process your team will actually use.

Why Structured Reviews Have Become More Urgent

The verification gap is real and growing. A 2026 Sonar survey found that 96% of developers do not fully trust AI-generated output, yet only 48% verify it before committing. That gap means code is shipping to production with lower average scrutiny than code written without AI assistance. The irony is that AI accelerates code production while simultaneously making the review step more important.

This is not unique to teams using AI coding assistants. The same pattern appears in any fast-moving team where shipping velocity is the primary metric and review quality degrades under pressure. A PRR does not replace code review. It reviews the system, not the code: the operational posture, the failure modes, the recovery paths.

The Five Areas Every PRR Must Cover

A production readiness review organized around five areas gives reviewers a consistent structure regardless of the system type.

1. Reliability

Can the system tolerate the failure modes it will actually encounter?

• Are there single points of failure in the critical path?
• What is the expected uptime target, and does the architecture support it?
• Are dependencies (databases, third-party APIs, queues) appropriately guarded with timeouts and circuit breakers?
• Has the team load tested to expected peak traffic, not just average traffic?
• Is there a defined degraded mode (what the system does when a dependency is unavailable)?

The most common gap here is that teams test the happy path thoroughly and the error path not at all. A circuit breaker that is never configured to open is not a circuit breaker.

2. Security

Can an attacker cause harm to users, data, or infrastructure?

• Are all endpoints authenticated and authorized appropriately?
• Is user data validated before it reaches the database or any downstream system?
• Are secrets managed outside of source code (environment variables, secrets manager, not .env files committed to the repo)?
• Are dependencies scanned for known CVEs?
• Are logs scrubbed to avoid leaking tokens, passwords, or PII?
• For AI-assisted codebases specifically: has the code been reviewed for hardcoded credentials, inverted access control, and injection vulnerabilities? (These are the four most common AI code vulnerability patterns.)

Security review does not require a full penetration test before every launch. It requires that someone has checked the common failure modes, not assumed they were handled.

3. Observability

When something breaks at 2am, can your on-call engineer understand what happened?

• Are structured logs emitted for all significant operations (requests, background jobs, external calls)?
• Are errors captured with enough context to diagnose root cause (user ID, request ID, input shape, stack trace)?
• Are the key service metrics instrumented: request latency (p50, p95, p99), error rate, saturation?
• Are there dashboards that show system health at a glance, without requiring log spelunking?
• Are alerts configured for conditions that require human intervention? Not for every anomaly, but for the ones that matter.
• Is distributed tracing in place if this service makes downstream calls?

The test: take a junior engineer who did not write this system. Give them a production alert. Can they diagnose it without waking the author? If no, your observability is incomplete.

4. Scalability

Will the system hold under the traffic it is expected to see, and can it grow without an emergency rewrite?

• What is the expected request volume at launch and at 10x launch?
• Are there known bottlenecks (database queries without indexes, synchronous operations that block the request thread)?
• Is the system stateless, or does horizontal scaling require shared state management?
• Are there resource limits set on containers/workers to prevent one bad request from starving others?
• Are background jobs separated from request-handling infrastructure?

Scalability is not about over-engineering. It is about knowing where the ceiling is before you need to raise it.

5. Operational Runbooks

When something goes wrong, do the people on-call know what to do?

• Is there a runbook for each alert type: what it means, what to check first, what the escalation path is?
• Is there a documented rollback procedure?
• Are database migrations tested for reversibility?
• Is there a defined incident communication template (what to tell users, what to log internally)?
• Does the on-call rotation include engineers who can actually remediate issues in this system?

This is the area most teams skip entirely. Runbooks feel like documentation, and documentation feels like overhead. But the first time you have a P0 at midnight with no runbook, you will write one, under pressure, while the system is down. Writing it in advance is cheaper.

The Scoring Model

A binary pass/fail for each checklist item misses the point. Some gaps are blockers; others are acceptable risks with a documented owner. The scoring model that works in practice has three levels:

Score	Label	Meaning
0	Blocker	Must be resolved before production traffic. No exceptions.
1	Conditional	Must be resolved within a specified window (e.g., 2 weeks post-launch). Owner assigned at review.
2	Observation	Noted risk. Team acknowledges it. No remediation required before launch.

A system with any score-0 items does not ship. A system with score-1 items ships with a remediation plan and a named owner. Score-2 items go into the backlog with a priority agreed upon in the review.

This model prevents two failure modes. The first is gates that always open because nobody wants to delay a launch. The second is reviews that block indefinitely because everything is treated as a hard blocker.

Checklist Template

Here is a structured PRR checklist formatted for use in a pull request, a Notion page, or a GitHub issue. Fill in the score (0/1/2) and owner for each item.

## Production Readiness Review

System: <name>
Review date: <date>
Reviewer(s): <names>
Launch target: <date>

### Reliability
| Item | Score | Owner | Notes |
|------|-------|-------|-------|
| No single points of failure in the critical path | | | |
| Uptime target defined and architecture supports it | | | |
| All external dependencies have timeouts configured | | | |
| Circuit breakers in place for unreliable dependencies | | | |
| Degraded mode defined and tested | | | |
| Load test completed at expected peak + 2x | | | |
| Database connection pooling configured | | | |
| Retry logic uses exponential backoff | | | |

### Security
| Item | Score | Owner | Notes |
|------|-------|-------|-------|
| All endpoints require authentication | | | |
| Authorization checked at the resource level, not just route level | | | |
| Input validated before reaching the database | | | |
| No secrets in source control | | | |
| Secrets managed via secrets manager or environment config | | | |
| Dependencies scanned for known CVEs | | | |
| Logs scrubbed of PII, tokens, and credentials | | | |
| SQL queries use parameterization or an ORM (no raw interpolation) | | | |

### Observability
| Item | Score | Owner | Notes |
|------|-------|-------|-------|
| Structured logs emitted for all significant operations | | | |
| Request ID propagated across service boundaries | | | |
| Errors captured with context (user ID, input shape, stack trace) | | | |
| Latency instrumented (p50, p95, p99) | | | |
| Error rate instrumented | | | |
| Saturation (CPU, memory, queue depth) instrumented | | | |
| Dashboard exists showing system health at a glance | | | |
| Alerts configured for actionable conditions | | | |
| Distributed tracing in place (if this service calls others) | | | |

### Scalability
| Item | Score | Owner | Notes |
|------|-------|-------|-------|
| Expected traffic volume at launch and at 10x documented | | | |
| Known bottlenecks identified and addressed or accepted | | | |
| Database queries analyzed with EXPLAIN for hot paths | | | |
| Indexes present on all columns used in WHERE, JOIN, ORDER BY | | | |
| Background jobs run separately from request handlers | | | |
| Container/worker resource limits set | | | |
| Horizontal scaling path documented | | | |

### Operations
| Item | Score | Owner | Notes |
|------|-------|-------|-------|
| Runbook exists for each alert | | | |
| Rollback procedure documented and tested | | | |
| Database migrations are reversible | | | |
| On-call rotation covers engineers who can remediate | | | |
| Incident communication template exists | | | |
| Post-mortem process defined | | | |

### Summary
| Blockers (0) | Conditionals (1) | Observations (2) |
|--------------|-----------------|-----------------|
| <count> | <count> | <count> |

**Decision:** [ ] Approved [ ] Approved with conditions [ ] Blocked
**Conditions (if applicable):** <list>
**Conditions due by:** <date>

Who Should Be in the Room

The PRR works best as a structured conversation, not a solo audit. The right attendees depend on team size, but the minimum set is:

Required:

• The engineer(s) who built the system. They know where the bodies are buried. The review will surface things they know but have not documented.
• The person who will be on-call when this system is in production. If they would not know how to respond to a failure, that is a gap.

Strongly recommended:

• A senior engineer or tech lead who did not build this system. They bring a fresh perspective and will ask the questions the author stopped asking.
• Someone responsible for security posture, if your team has that role.

Avoid:

• Reviewing async without synchronous discussion. The checklist reveals what to look at; the conversation reveals why it is or is not a problem.
• Reviews with more than six attendees. Larger groups diffuse accountability and slow decisions.

The reviewer who did not build the system is the most valuable person in the room. They are the closest proxy for the on-call engineer who will inherit this at 2am six months from now.

Gate vs. Approve with Conditions

The decision at the end of a PRR is not binary. Three outcomes are possible:

Approved. No score-0 items. Score-1 items have named owners and agreed timelines. The system ships.

Approved with conditions. No score-0 items, but score-1 items require remediation within a defined window. The system ships, but there is a written commitment with dates and owners. The tech lead or engineering manager tracks this list, not the original reviewer.

Blocked. One or more score-0 items. The system does not ship until those are resolved. The review reconvenes (usually a lighter follow-up, not a full re-review) once the blockers are addressed.

The “approved with conditions” category is where many teams struggle. It requires discipline to actually close those items after launch, when pressure has moved to the next feature. Making the conditions visible in a shared tracking system (not just the review document) and assigning a check-in date prevents this from becoming a permanent backlog.

Building a Repeatable Process

A one-time PRR is useful. A PRR that becomes a habit is where the compounding value comes from.

A few practices that make the process stick:

Scope it to the system, not the team. Run a PRR for each system that reaches production, not as a team-level ritual. This keeps reviews appropriately sized and prevents review fatigue.

Start with a lightweight version. If your team has never run a formal PRR, start with the five areas and a short checklist per area. Add items as your own postmortems reveal gaps. The checklist should evolve with your systems.

Make the output visible. Store completed PRR documents in your engineering wiki, linked from the relevant service documentation. When a new engineer joins and gets added to on-call for a system, they should be able to find the most recent PRR and the open conditionals from it.

Tie it to your deployment process. At minimum, require a completed PRR before any system enters production for the first time. For significant changes to existing systems (new external dependencies, major architectural changes, new data storage), run a scoped re-review covering just the affected areas.

Do not automate the decision. Checklists can be automated; judgment cannot. Automated security scanners, coverage thresholds, and load test pass criteria are useful inputs to a PRR. They do not replace the conversation.

The AI Code Verification Gap

The data on AI-assisted code quality makes the PRR more important, not less. When 96% of developers distrust AI output but only 48% verify it before committing, the gap between “written” and “reviewed” widens. The code ships with lower average scrutiny.

This is not an argument against using AI coding tools. It is an argument for making the verification step explicit and structured rather than assuming it happened during code review.

For teams where AI-generated code represents a significant portion of the codebase, the security section of the PRR deserves extra attention. The four vulnerability patterns that appear most frequently in AI-generated code are: missing authentication checks, SQL injection via direct string interpolation, hardcoded secrets in configuration files, and inverted access control logic (checks that pass when they should fail). A targeted review for these four patterns, before production launch, catches the category of errors that AI tools most reliably introduce.

If you are assessing a codebase you did not write, including one that was vibe-coded by a founder using AI tools, the PRR structure gives you a framework for assessing production-worthiness systematically. The same five areas apply. The scoring model gives you a way to communicate findings that distinguishes blockers from acceptable risk.

The Return on Time Invested

A full PRR for a new system takes two to four hours. A lightweight re-review for a scoped change takes thirty minutes to an hour. That investment is cheap compared to a production incident that requires four engineers for six hours, costs customers real harm, and generates a postmortem that surfaces the exact gaps the PRR would have caught.

The value is not in the checklist itself. It is in the conversation the checklist forces. Someone has to answer “who is on-call for this?” Someone has to answer “what happens when the payment provider is unavailable?” Someone has to answer “where are the credentials stored?” If those answers exist in someone’s head but not in a runbook or a monitoring dashboard, the PRR is where that gap becomes visible and fixable before it becomes a 2am problem.

Build the habit before you need it. The postmortem will always recommend it after the fact.