A production readiness review, or PRR, is the check where someone who did not build the app reads the evidence that it is ready and decides: go, no-go, or go with dated conditions. Google’s SRE book considers it a prerequisite before an SRE team takes on running a service. For a small team, my working rule is about an hour.
What a production readiness review is, and what a production readiness review checklist holds
A production readiness review is a decision, and the report is only its input: a reviewer who did not build the app reads the readiness report, opens the evidence behind every failure and a few passing rows, watches one live check, and decides on go, no-go, or go once named conditions are met by their dates.
The review is the last step in what a developer handoff looks like: the point where someone other than the builder has to accept the app as it stands. That is my definition of a production readiness review for one app and a small team, and it borrows its shape from a much larger original.
The original is the Google SRE production readiness review. In Google’s SRE book on the production readiness review, a PRR is a process that identifies the reliability needs of a service based on its specific details, and it is considered a prerequisite for an SRE team to accept responsibility for managing the production aspects of a service. The book says a PRR can be started at any point of the service lifecycle. It groups what SRE cares about under one word, production, and lists six aspects in this order: system architecture and interservice dependencies; instrumentation, metrics, and monitoring; emergency response; capacity planning; change management; and performance (availability, latency, and efficiency). In the Analysis phase, the reviewers aim to gauge the service’s maturity along those axes, and the book adds: “Usually, the SRE team establishes and maintains a PRR checklist explicitly for the Analysis phase.”
Three things get mixed up under this name. The checklist is the list of items, each with a test: that is the production readiness checklist. The report is that checklist filled in with results and evidence, the kind of record that belongs in technical documentation for investors. The review is the decision someone makes after reading the report. So a production readiness review checklist, for the reviewer, is a list of questions rather than items, and the eight questions further down are the production readiness review template I’d start from.
Production readiness itself is a state you can show evidence for, and a feeling doesn’t count. What that means for the code, in full, is covered in what makes code production ready. For one platform’s version of the same questions, see is Bolt.new production ready.
What is a readiness review? PRR, TRR, ORR and the manufacturing kind
A readiness review is a gate before the next phase: a production readiness review before live use, a test readiness review before formal testing, an operational readiness review in some companies’ vocabulary. Defense and manufacturing use the same names for hardware production, a different discipline.
- A production readiness review, in software, is the review on this page. In defense acquisition it is a review of whether a system’s design is ready for production, normally performed as a series of reviews toward the end of the Engineering, Manufacturing, and Development (EMD) phase, per AcqNotes’ entry on the defense PRR.
- A test readiness review is conducted to determine if a system is ready to proceed into formal testing, in AcqNotes’ test readiness review entry; the FAQ below lists what it covers.
- An operational readiness review is, in my reading, a name some teams use for the same software check.
- A manufacturing readiness review or assessment belongs to hardware production, a separate discipline that this page leaves alone.
The nearest defense term to a technical readiness assessment is the technology readiness assessment, which AcqNotes describes as “a formal, metrics-based process and accompanying report that assesses the maturity of critical hardware and software technologies.” AcqNotes says it is conducted by an Independent Review Team at set program milestones, which puts it a long way from an hour-long meeting about a web app.
Why it matters for a small team
Of the 26 apps I audited in June and July 2026, 22 landed in the red band, 4 in amber and none in green. Those 26 are a selected set: 21 third-party apps (11 public apps and a held-out set of 10) plus 5 of my own, not a random sample and not a rate for AI-built apps in general.
The deploy gate tells the same story from another side. In the same June and July audits, at least 17 of the 21 third-party apps had no deploy gate, and so did all 5 of my own: every push ships straight to production with nothing checking it first.
My reading of that: in those apps, the builder alone decided when the app was done. A review is the one place where somebody else decides. Without a reader, a readiness checklist is a document nobody opens, and its “not applicable” rows are the easiest place for a gap to hide. My working rule is that a row marked not applicable needs a written reason the reviewer can challenge.
How to run the review in one hour
A small team’s production readiness review takes about an hour by my working rule, and six steps: a reviewer who did not build it, the report sent a day ahead, failures and not-applicable reasons read first, a few passes checked, one live check, and a written decision with dates.
- 01 Pick a reviewer who did not build the app. Evidence: their name in the report.
- 02 Send the report, the architecture diagram and the runbooks a day ahead. Evidence: the sent message with its date.
- 03 Read every failure first, then every not-applicable reason, then three passing rows picked at random, opening the evidence behind each. Evidence: the list of rows opened.
- 04 Run one live check in the room: a rollback on staging or a restore of yesterday's backup. Evidence: the time taken and the result.
- 05 Decide go, no-go, or go with conditions, each condition with an owner and a date. Evidence: the decision line.
- 06 Write the decision and its conditions into the report. Evidence: the report's updated version.
The timings are my working rules, not a standard: about an hour, the report sent a day ahead, three passing rows opened at random. Step 5 is the decision itself; for a fuller format to record a launch call in, the seven-gate launch verdict is one, and these six steps feed it.
Written down with a reviewer and a date against each step, these six steps are the whole production readiness process for one app. A production readiness plan is the same list with the reviewer’s name and the meeting date filled in before the day. When a larger customer asks you to audit production readiness before they sign, this hour with a signed decision line is what you can show them. A final production readiness review is the last run before launch, held once the conditions from an earlier run are closed. A pre-ship readiness review is the same meeting held before one release ships instead of before launch. Kept together, the report, the list of rows opened, the live check’s result and the decision line make your production readiness review example, and the sample the next reviewer starts from. To make production readiness observable between reviews, keep the report as a living table that changes when a row changes, not a PDF snapshot that goes stale the week after.
Before the hour: entrance criteria and what the reviewer receives
My working rule for the production readiness review entrance criteria: the review does not start until the report lists every item with a result, every failure is visible, and the reviewer has the architecture diagram, the runbooks and the list of accounts with their owners. Anything missing moves the meeting, because a reviewer who has to ask where the diagram is will spend the hour on logistics.
Those three conditions are the production readiness review requirements, and nothing else is needed on the day. The runbooks should follow a runbook template so the reviewer can find the restore steps without asking. The wider documentation set the reviewer reads is laid out in how to write technical documentation.
The eight review questions
The reviewer’s checklist is 8 questions, each answered by opening something: the failed rows, the not-applicable reasons, the evidence behind a passing row, the rollback record, the restore test, the alert route, the capacity basis and the account owners.
The questions and what each one opens are my list. The third column maps each question to one of the six aspects of production from Google’s chapter; the aspect names are Google’s, and the mapping is mine.
| # | The question | What the reviewer opens | Google SRE aspect of production it covers |
|---|---|---|---|
| 1 | Is every failure visible? | The report’s failed rows | Change management |
| 2 | Does every not-applicable row have a reason? | The written reasons | Change management |
| 3 | Does the evidence open? | The evidence behind three passing rows | System architecture and interservice dependencies |
| 4 | Can the app be rolled back? | The last rollback record | Change management |
| 5 | Can the data be restored? | The last restore test’s date and result | Emergency response |
| 6 | Who is paged when it breaks? | The alert route and a test alert | Instrumentation, metrics, and monitoring |
| 7 | What is the capacity statement based on? | The load test or the stated limit | Capacity planning |
| 8 | Who owns every account? | The account list with owners | Emergency response |
These eight rows are the software production readiness review checklist a small team needs, while the PRR checklist an SRE team keeps at Google is specific to each service and generally based on domain expertise, experience with related or similar systems, and best practices from its Production Guide.
In one point-of-sale app I audited in July 2026, the written data model described columns the schema did not have. A reviewer who only read the documents would have passed a data model that wasn’t there, which is why the question opens the evidence and never stops at the description.
The live check: production readiness testing in the room
The reviewer watches one test in the room, never a slide: roll the app back on staging, or restore yesterday’s backup into a scratch database and count the rows. The time it took and the result go into the report as evidence.
Both checks need something your host’s plan may not give you: a staging environment for the rollback, and a kept backup for the restore. Where either is missing, that absence is the review’s first finding. Production readiness testing, for a small team, is this one live check plus the tests the report already records. The promotion gate that makes a rollback possible at all is part of the release readiness checklist.
These are checks for you to run on systems you own; I did not run them for this article.
The AWS Well-Architected Review: the questions it asks, and what a small team should take from it
The AWS Well-Architected Review is meant to be a lightweight process, hours not days, run as a conversation rather than an audit, on questions grouped under the framework’s six pillars. A small team borrows its question style and its reliability and security pillars, then adds a reviewer who did not build the app.
AWS’s review process says the review “should be a lightweight process (hours not days) that is a conversation and not an audit,” and that its outcome “is a set of actions that should improve the experience of a customer using the workload.” AWS says reviews should be applied at key milestones, early in the design phase and then before the go-live date. It also recommends that the team members who build an architecture use the framework to review it continually, rather than holding a formal review meeting, though the same page describes an approach for reviewing another team’s workload.
The questions sit under the pillars of the AWS Well-Architected Framework, which AWS names as “the six pillars of operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability.” AWS describes the framework as documenting “a set of foundational questions” and neither page puts a number on them.
The difference, as I read it: AWS leans toward builders checking their own work continually, and the PRR always brings in someone who did not build it. What a small team on a managed host takes from the AWS Well-Architected review questions is their style, where every answer points at evidence, plus the reliability and security pillars. The cost and sustainability pillars mostly show up on the hosting bill.
Readiness assessment templates: project, business and test readiness reviews
Three other reviews share the vocabulary. The cells are my reading, except the test readiness row, which follows AcqNotes.
| Review | Who runs it | What it decides | The one artifact it reads |
|---|---|---|---|
| Project readiness assessment | The project manager | Whether the plan, budget and staff are in place to start | The project plan |
| Business readiness assessment | The business owner of the go-live | Whether the people and processes are ready: training, support, the teams who will run it | The training and support plan |
| Test readiness review | The test manager and the program manager | Whether the system is ready to enter the testing phase | The completed and approved test plans |
A project readiness assessment is a project-management gate, and the rest of this page has little to add to it. A business readiness assessment template is the people half of a go-live, with rows for training, support and the teams who will run the system. A test readiness review, in its defense form, is covered in the FAQ below; for a software team it is the check before formal testing starts. A production readiness plan for QA, in my reading, is that test readiness gate plus the live check above.
There is no download here on purpose: the table is the template. A project readiness checklist template in Excel is these four columns copied into a sheet, one row per review, and a business readiness checklist template is the same sheet with its own rows added.
How to check your own app
Run the review on yourself once: fill the report, hand it to someone outside the team for an hour, and count how many of the eight questions they can answer from the report alone. Each one they cannot answer is next week’s work.
If that outside reader is taking the app over, a software project handover checklist is the list they work through, and knowing how to run a technical handover session helps, because that session is the same meeting with the receiver in the reviewer’s chair.
The evidence to keep is short: the list of questions the outside reader could not answer, with the date you ran it.
Where the sprint does this
On the Production Hardening Sprint, the last phase, days 8 to 10, is verify and hand over. Deliverable 13.1, the production readiness report, gives the result for every scope item, the work completed and its verification evidence, and that report is the input a review like this one reads. We verify it this way: account for all 123 IDs, keep failures visible until resolved, and explain genuine non-applicable items. Deliverable 13.4 is a recorded 60-minute walkthrough with the client team and technical advisors, verified by delivering the recording, supporting documents, and answers or follow-ups from the session. Formal third-party certifications and independent audit opinions are separate from these engineering deliverables. Every deliverable is listed in the published scope.
Common questions about PRRs and other readiness reviews
What should be included in a test readiness review?
A test readiness review should cover test objectives, test methods and procedures, the scope of tests, and safety, and confirm that the required test resources are identified and coordinated; it also checks that planned tests trace to program requirements and user needs, and assesses development maturity, cost and schedule effectiveness, and risk. That is AcqNotes’ defense definition, and its typical success criteria include completed and approved test plans, coordinated test resources, earlier test results that form a satisfactory basis for the planned tests, and a risk level acceptable to program leadership.
For a software team, my reading is that the same idea shrinks to the checks you want settled before formal testing starts: what is being tested, with which data, and who signs off.
What is a product readiness review?
A product readiness review is, in my reading, usually another name for the production readiness review, which in defense and manufacturing AcqNotes defines as the review that “determines if a systems design is ready for production and if the system developer has accomplished adequate production planning to enter Low-Rate Initial Production (LRIP) and Full-Rate Production (FRP).” The software review on this page is a different discipline that shares the name.
What is srr, pdr, and cdr?
SRR, PDR and CDR are three defense technical reviews, not software release checks. In AcqNotes’ words, the System Requirements Review is “a multi-disciplined technical review to ensure that the developer understands the system requirements and is ready to proceed with the initial system design”; the Preliminary Design Review is “a technical assessment that establishes the Allocated Baseline of a system,” held before detailed design work starts; and the Critical Design Review is “a multi-disciplined technical review that establishes the initial product baseline.”
What is the purpose of a readiness assessment?
The purpose of a readiness assessment is to decide, with evidence, whether something may move to its next phase, and to name the conditions if it may.
If this checklist left you with more open items than you expected, the sprint below works through all of them in ten working days.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase