A production readiness review was designed for companies with a reliability team. Most AI-built products launch without one, which is why the review matters more for them, not less. When a product is built with an AI app builder such as Lovable, Bolt, Replit or Cursor, the founder usually becomes its operator as well: the person who gets the message when bookings stop or a customer sees the wrong data.
A production readiness review (PRR) gives that founder the view an operations team would normally bring. This article covers what the review checks, when to run it, who fills each role and how to reach a launch decision. The wider method for ai-generated code in production is in our founder’s guide.
TL;DR
A production readiness review (PRR) is a structured check, before launch, of whether a product can be run safely and reliably for real users, not only whether the code works. For an AI-built product, the review is done by someone independent of whoever, or whatever tool, wrote the code. It ends in a launch decision: go, go with conditions, or not yet.
- A production readiness review of an AI-built product covers five areas: security and data, code and architecture, reliability and critical flows, deployment and operations, and maintainability and code ownership.
- A production readiness review should start before the first paying users, an enterprise pilot or a handover to a new developer, early enough that every release blocker can be fixed before the launch date.
- A production readiness review needs three roles: an owner who fills in the PRR document and fixes findings, an independent reviewer who did not build the product, and a decision-maker, usually the founder or COO.
- The launch decision has three outcomes: not yet while any release blocker such as exposed production credentials is open, go with conditions when every open finding has an owner and a deadline, and go when nothing material remains.
What is a production readiness review?
A production readiness review is a structured check of whether a product can be operated safely for real users before it goes live. Some teams call it a production readiness assessment or a launch readiness review; the practice is the same. “Production” is the live environment where real customers, real data and real money are involved. The review asks a different question from testing: not “does the feature work?” but “what happens to users, data and the business when something fails at 2 a.m.?”
The production readiness review comes from Site Reliability Engineering (SRE), the discipline of the engineers who keep production systems running. Google’s Site Reliability Engineering book (Beyer, Jones, Petoff and Murphy, O’Reilly, 2016) describes the PRR as “a process that identifies the reliability needs of a service based on its specific details”. Google’s SRE teams ran the review before they agreed to take over a service from the developers who built it.
Production readiness, in plain terms, means the product can handle real users, real data and failures without its builder watching it. A product is production ready when someone other than its builder can run it, see when it breaks and recover it.
The production readiness review has since spread well beyond Google. In the USENIX ;login: article “Production Readiness Reviews: A Surprisingly Versatile Practice” (April 2025), Pedro Alves recommends reviewers who are external to the team being reviewed, calls two reviewers “the sweet spot” and reports two to four working sessions as typical. Those three conditions — an independent reviewer, a written document and a small number of focused sessions — carry over directly to an AI-built product.
Why an AI-built product needs a different review
A classic production readiness review assumes three things: an operations team that will run the service, documented architecture and engineers who know the code. An AI-built product often has none of the three. The founder is the operator, and much of the code was generated by a tool and never read line by line by a person.
That gap changes what the review has to find. Google’s Simple PRR Model has six stages, from engagement to continuous improvement, and the fifth stage, onboarding, is the moment an SRE team accepts responsibility for the service. Nobody takes over an AI-built product after its review. The production readiness review replaces the missing operations team’s view, so it has to surface the unknowns the founder cannot see from a demo.
| Classic PRR | PRR for an AI-built product | |
|---|---|---|
| Who built it | Engineers in a product team | A founder, a freelancer or a small team working with an AI app builder |
| Who will run it | An SRE or operations team with an on-call rota (a schedule of who responds to incidents) | The founder, usually without an on-call rota |
| What is unknown | Edge cases, load behaviour, failure between services | Which code paths exist, which access rules apply and which third-party services hold data |
| Documentation | Architecture notes and runbooks (written instructions for known incidents) exist | Little or none; the code is the only record |
| Typical release blockers | Missing alerts, untested failover, capacity limits | Open access rules, credentials in the frontend, payment or personal-data flows nobody has tested |
| Who reviews | SRE engineers from outside the product team | An independent engineer or review partner who did not build the product |
We’d recommend keeping the classic PRR areas as the frame and asking the AI-built unknowns first, because release blockers tend to sit in code nobody has read. A product with documented architecture and an experienced developer can run a lighter version; a founder-operated product with payment or personal-data flows needs the full review.
What a production readiness review covers
A production readiness review of an AI-built product covers five areas: security and data, code and architecture, reliability and critical flows, deployment and operations, and maintainability and code ownership. Each area maps to a classic PRR concern; the difference is the order of questions. The reviewer first establishes what the code actually does, then how well it does it.
Access rules come first for a reason. The OWASP Top 10:2025, the Open Worldwide Application Security Project’s ranking of web application risks, lists Broken Access Control as risk number one (A01:2025).
| Classic PRR area | Area in an AI-built product | What the review checks | Example release blocker |
|---|---|---|---|
| Security | Security and data | Access rules per role, where credentials live, where personal data is stored | A payment provider’s secret key is readable in the frontend code |
| Architecture and dependencies | Code and architecture | Where business logic runs, which services the app depends on, unused code paths | Prices or permissions are calculated only in the browser, so a user can change them |
| Reliability | Reliability and critical flows | What happens when sign-up, payment or booking fails halfway; tests on those flows | A failed payment still confirms the order |
| Observability, deployment and rollback | Deployment and operations | Observability (logs and alerts that show what the system is doing), releases, rollback (returning to the last working version), backups | Backups have never been restored, so a failed release can lose customer data |
| Ownership | Maintainability and code ownership | Who holds the repository, hosting and domain accounts | The code repository sits in a former freelancer’s personal account |
Each area has a longer item list in the production readiness checklist. How deep an independent audit goes inside each area is explained in our article on the ai code audit.
If your app calls an AI model
This part of a production readiness review is not an evaluation of the AI model’s accuracy; model evaluation is a separate discipline. When an app sends user input to a model provider, the review adds four questions.
- Can a user steer the model? The OWASP Gen AI Security Project says prompt injection occurs “when user prompts alter the LLM’s behavior or output in unintended ways”.
- Which personal data goes to the model provider, and is there a processor agreement as GDPR Article 28(3) requires?
- What does the app do when the provider times out or rate-limits requests?
- Is there a spend cap on model usage? OWASP lists “denial of wallet” attacks under LLM10:2025 Unbounded Consumption.
The checklist items for AI-model features are in the same production readiness checklist.
Launching in the next few weeks, without an operations team to review it?
An AI-built product review gives you the independent view a production readiness review needs: engineering and security reviewed together, findings explained in plain English and ranked by what blocks launch and what can wait.
When to run a production readiness review
A production readiness review should run before the product carries real risk for someone other than the founder. Four moments trigger one:
- before the first paying users or a public launch;
- before an enterprise pilot or a customer’s security questionnaire;
- before handing the product to an agency, a new developer or on-call support;
- after a major change, such as a new payment flow, a new type of personal data or a rebuild.
The timing rule is simple: start early enough that every release blocker can be fixed and re-checked before the launch date, and never in launch week. The USENIX ;login: guidance of two to four review sessions, plus one or two Q&A sessions, sets the minimum calendar before any fix work starts. We’d recommend starting before an enterprise pilot, not after, because the pilot customer’s security questionnaire asks for the same evidence the review produces.
A production readiness review is proportionate to risk. Payment flows and personal data get the full review; an internal tool used by five colleagues gets a lighter one. For products that process personal data, GDPR Article 32(1)(d) calls for “a process for regularly testing, assessing and evaluating the effectiveness” of security measures, so a re-review after each major change belongs in the release plan.
Who should do the production readiness review?
A production readiness review needs three roles, and in a small company the rule that matters most is that the reviewer did not build the product. Which review method fits, from an AI self-check to a penetration test, is compared in who should review AI-generated code. Inside a PRR, the question is who does what.
Three roles: owner, reviewer, decision-maker
| Role | Who in a small company | Responsibility |
|---|---|---|
| Owner | Founder or lead developer | Fills in the PRR document, answers the reviewer’s questions, fixes findings |
| Reviewer | An independent engineer or review partner who did not build the product | Reads code, configuration and the PRR document; ranks findings by launch impact |
| Decision-maker | Founder or COO | Decides go, go with conditions or not yet, and owns the conditions |
The technical co-founder or freelancer who built the app is the right owner and the wrong sole reviewer: a builder reviews against their own assumptions, so the cases they never considered stay untested. In a small company, one independent review partner covering engineering and security together fills the reviewer’s seat.
What to look for in a reviewer
A reviewer for a production readiness review of an AI-built product should meet five criteria:
- Has run production systems. The reviewer has been on call, restored a backup and rolled back a broken release.
- Reviews engineering and security together. In an AI-built product an open access rule is a code finding and a security finding at the same time.
- Is independent of the fix work. The review is scoped and delivered separately, so findings are not shaped by a follow-up contract.
- Explains findings in plain English. Every finding states its impact on users, data or revenue.
- Will tell you “not yet” with reasons. Ask a prospective reviewer for an example of a “not yet” they have reported and what changed afterwards.
How the review runs: from PRR document to decision
A production readiness review runs in four steps, from a one-page document to a decision meeting. Google’s Simple PRR Model needs six stages because it ends with an SRE team taking over the service; an AI-built product needs only the steps that lead to a decision.
- The owner fills in a one-page PRR document before the first session.
- The reviewer reads code, configuration and the document and asks questions in working sessions; two to four sessions is the typical range USENIX ;login: reports.
- The reviewer ranks findings by launch impact: release blocker, condition or later.
- The decision-maker holds a decision meeting and records the outcome, the conditions and an owner and deadline for each condition.
Go, go with conditions or not yet: making the launch decision
A production readiness review ends in one of three outcomes, and the decision belongs to the founder; the review provides the evidence. A product with an open release blocker is not ready, whatever the launch date says.
| Outcome | When | What happens next |
|---|---|---|
| Go | No release blockers open; remaining findings have low impact | Launch as planned; log the remaining findings in the backlog |
| Go with conditions | No release blockers open; every open finding has an owner, a deadline and a restricted-launch decision | Launch to a limited group of users or behind a feature flag (a switch that turns a feature on for selected users only); check each condition on its deadline |
| Not yet | At least one release blocker is open | Fix the blockers, re-review the fixed items, set a new decision date |
Three kinds of finding are release blockers: exposed production credentials, confirmed unauthorised access to sensitive data, and failures that create unacceptable privacy or payment risk. How these blockers show up in AI-built apps is described in vibe coding security risks.
The stakes of a personal-data blocker are fixed in law. Under GDPR Article 33, a personal data breach must be reported to the supervisory authority, in the Netherlands the Autoriteit Persoonsgegevens, within 72 hours of becoming aware of it.
“Go with conditions” works only when the conditions are written down. Each open finding gets an owner, a deadline and a decision on how far the launch is restricted until the finding is closed. If a condition passes its deadline unresolved, the restriction stays in place; it does not lapse. After launch, two of the five DORA software delivery metrics, change fail rate and failed deployment recovery time, show whether the conditions held. A change fail rate that rises in the first weeks is a signal to keep the launch restricted.
Production readiness review example: an AI-built booking app
Illustrative example — a fictional product, not a client case. A founder has built a booking app for physiotherapy clinics in the Netherlands with an AI app builder and one freelance developer. Three clinics use it in a pilot, and twenty more are due to start in six weeks. The production readiness review produced five findings.
| Area | Finding | Classification |
|---|---|---|
| Security and data | Patients can see other patients’ bookings by changing the booking ID in the URL | Release blocker |
| Security and data | The Stripe secret key is readable in the frontend code | Release blocker |
| Deployment and operations | No alert when booking confirmation emails fail | Condition |
| Reliability and critical flows | No tests on the cancellation flow | Condition |
| Maintainability and code ownership | No README or setup instructions | Later |
The first decision was not yet, because two release blockers were open. The freelancer moved access checks to the server, rotated the Stripe key and moved it to a server-side secret store; the reviewer re-checked both fixes. The second decision was go with conditions: email alerting before any new clinic starts, cancellation-flow tests within four weeks, and launch limited to the three pilot clinics plus five new ones until both conditions close.
A booking at a physiotherapy clinic reveals that a patient is receiving treatment, which makes it data concerning health, a special category under GDPR Article 9.
How Sunbytes checks your release before launch
The two release blockers in the booking-app example — a changed booking ID that opens another patient’s appointments and a payment key readable in the frontend — surfaced by reading the code, not by clicking through the demo. Reading code and configuration with fresh eyes is the part of a production readiness review a founder cannot do alone, and it is the part Sunbytes takes on.
With the AI-built product review, Sunbytes fills the reviewer’s seat in your PRR. A reviewer who did not build the product reads the code and configuration across security and data, code and architecture, reliability and critical flows, deployment and operations, and maintainability and code ownership. An open access rule is logged as a code finding and a security finding at once, and every finding gets one of three launch labels: release blocker, condition or later. You receive a prioritised action plan in plain English, so the decision — go, go with conditions or not yet — stays with you and rests on evidence. The review is scoped separately from any fix work, which keeps the findings free of a follow-up contract.
Two other Sunbytes teams join only when the findings call for them. When an enterprise pilot customer asks for security evidence beyond the review, such as access management, key handling or GDPR records, Cybersecurity Solutions puts those controls in place. When closing the blockers before the launch date needs more engineers than you have, a dedicated software development team takes on the fix work as a separate engagement, so the reviewer never grades its own colleagues’ fixes.
Access to your repository and production configuration runs under Sunbytes’ ISO/IEC 27001-certified information security management system, with governance from the Dutch headquarters and engineering from the Vietnam delivery hub. For a product that holds patient bookings or payment data, that access control matters as much as the findings: the reviewer works inside exactly the systems the review is meant to protect, backed by 15+ years of software delivery.
If your launch date is already set, book an AI-built product review early enough to fix and re-check every release blocker before that date.
