A launch date should follow evidence that the product can be operated safely. A production readiness checklist gives a founder and developer a shared record of verified conditions and unresolved gaps.
This article covers 35 product checks across six areas, six personal data checks where GDPR applies, and three routes for reading your result. The free spreadsheet and PDF record the same questions.
TL;DR
A production readiness checklist is a list of yes/no checks for a product’s ability to handle real users, personal data and foreseeable failures. For an AI-built product, record evidence for each answer and resolve launch blockers before customer use. Completing the checklist does not certify the product as safe.
- The 35 product checks cover security and access, code and architecture, reliability and critical flows, deployment and operations, maintainability and code ownership, plus seven checks for products that call an AI model.
- The six personal data checks cover necessary collection, private defaults, deletion requests, data locations, processor agreements and breach ownership, each mapped to the relevant GDPR provision.
- Result routing starts with blockers: any applicable B item answered “no” or “don’t know” means fix or verify first; three or more unknowns indicate a need for independent review.
The founder’s guide to AI-generated code in production provides the wider context.
What is a production readiness checklist?
A production readiness checklist records the conditions software must meet before customers depend on it. Production readiness means operating within the intended use and recovering from foreseeable failures without the builder watching every interaction. The checklist makes those conditions verifiable.
An AI-built product needs these checks even when the finished application never calls an AI model. The seven model checks apply only when a live feature sends model requests.
A checklist is a self-check; an independent production readiness review examines the product and tests the evidence. Release planning addresses how the checked version reaches users. A completed form alone does not approve launch.
How to use the production readiness checklist
The production readiness checklist works best when the founder and developer complete it together: the founder confirms ownership and intended use; the developer demonstrates technical controls. Answer yes, no or don’t know. A “yes” needs evidence, such as a test result or configuration record, with the product version and date.
B marks a minimum launch gate. Treat “don’t know” as unresolved, like “no”, until someone verifies the answer. Start before setting a launch date and repeat affected checks after major changes.
Use N/A with a written reason, for example for payments in a product without a payment flow. An unperformed check is not N/A. The B labels and three-unknown review trigger are practical prioritisation rules, not a certification or statistical score.
The production readiness checklist for AI-built products
The checklist contains 28 general product checks and seven conditional AI-model checks. B identifies 12 potential launch gates, including conditional payment and model items. An item without B can still block launch when testing confirms unacceptable exposure.
Security and access
These eight security and access checks form a vibe coding security checklist with the same evidence requirements as other software. OWASP Top 10:2025 A01 places access enforcement in trusted server-side code or APIs. The vibe coding security risks guide explains the risks.
| # | Check | Why it matters | B |
|---|---|---|---|
| 1 | Are login and permission checks enforced on the server for every protected request? | Server-side checks run on your backend, beyond a visitor’s control. | B |
| 2 | Have two test accounts confirmed that changing a record ID cannot expose another user’s private data? | A successful login must still respect each customer’s data boundary. | B |
| 3 | Are private API keys and other secrets absent from browser code and repository history? | Publishable keys differ from credentials that grant privileged access. | B |
| 4 | Have all previously exposed secret keys been replaced and the old keys disabled? | Removing a visible key does not stop a copied key from working. | B |
| 5 | Are database permissions enabled and tested for every table exposed to users? | Each exposed table needs rules that match its intended readers and writers. | B |
| 6 | Do administrator accounts require multi-factor authentication? | An extra verification step protects accounts with wider access. | |
| 7 | Are incoming values validated on the server before they affect data or actions? | Browser checks alone can be bypassed by direct requests. | |
| 8 | Have third-party packages been scanned and security findings assessed for exploitability? | A scan result needs a decision about the affected version and exposure. |
For leaked API keys, distinguish private credentials from intentionally publishable identifiers. Record replacement evidence against items 3 and 4.
Code and architecture
These four code and architecture checks establish whether the product can be understood and built consistently. Ask where critical rules live and which dependency versions are used. OWASP A03:2025 covers dependency tracking and control of build changes.
| # | Check | Why it matters | B |
|---|---|---|---|
| 9 | Are critical business rules documented in one place, without conflicting payment or login logic? | Repeated rules can produce different results across the same product. | |
| 10 | Are development, staging and production separated, with their own data and secrets? | An environment is a separate setup for building, testing or serving users. | B |
| 11 | Are package versions fixed in a lockfile and their licences recorded? | A lockfile records dependency versions so builds can be reproduced. | |
| 12 | Can another developer explain the data model and where critical rules run? | Understanding must survive the original builder’s departure. |
Reliability and critical flows
These six reliability checks establish what happens when customer journeys fail and recover. OWASP’s error handling guidance separates internal error records from information returned to users.
| # | Check | Why it matters | B |
|---|---|---|---|
| 13 | Have applicable critical flows, including signup, login, payment and data export, passed end-to-end tests? | B applies when payments are offered; check failed and repeated payments too. | B |
| 14 | Do failures show a useful user message and record technical details privately? | Users need a next step without seeing internal errors or credentials. | |
| 15 | Do external calls have timeouts and bounded retries that cannot repeat a payment or other write? | Retries need safeguards against carrying out the same action twice. | |
| 16 | Do automatic backups run on a documented schedule? | A schedule makes the possible gap in recovered data visible. | |
| 17 | Has a backup restore been tested with a recorded result? | A completed backup job does not prove that recovery works. | |
| 18 | Has the product been tested while a critical external service is unavailable? | The product should fail safely and show an honest status. |
For payments, record the customer-visible status and the provider’s result after a timeout. A screenshot of a working checkout page is insufficient evidence for item 13.
Deployment and operations
These five deployment and operations checks confirm failure detection and recovery. They are readiness gates; the AI deployment checklist covers the release sequence. Keep detailed rollout instructions in the release plan.
| # | Check | Why it matters | B |
|---|---|---|---|
| 19 | Does a tested failure alert reach a named person? | Someone must receive the alert and know they own the response. | B |
| 20 | Are usable logs available without passwords, secret keys or unnecessary personal data? | Logs should help investigate events without creating another exposure. | |
| 21 | Can the team restore a previous working version and handle any changed database structure? | Rollback means returning to a working version with compatible data. | B |
| 22 | Do releases follow a recorded, repeatable process with a review before production? | A second person should be able to follow the same release record. | |
| 23 | Is a named person responsible for the live product and its external services? | Ownership includes supplier accounts and incident decisions after launch. |
A rollback also depends on database compatibility. An old build that starts but cannot read current records is not a working recovery option. Ask for evidence of the recovery path.
Maintainability and code ownership
These five maintainability and code ownership checks confirm that your company can operate the product when contributors change. A README counts as evidence only when someone else has followed it successfully.
| # | Check | Why it matters | B |
|---|---|---|---|
| 24 | Does the company control the repository, hosting, billing and domain accounts? | A repository stores code and its history; company access must outlast a contract. | B |
| 25 | Is the list of people and services with access up to date? | Remove former contributors and unexplained service accounts. | |
| 26 | Has another developer used the README to run the product without the builder’s help? | A README is the written setup guide shipped with the code. | |
| 27 | Do repeatable tests cover the critical flows when the code changes? | A one-off successful test must remain checkable after later edits. | |
| 28 | Are known issues recorded with an owner and a next action? | Written issues can be prioritised and handed over. |
If your product calls an AI model
Products that call an AI model need seven additional checks covering the connection between the model, your data and the actions the product permits. Least privilege means granting only the minimum permissions needed. Prompt injection means an instruction in user input or external content attempts to redirect the model’s behaviour. OWASP’s prompt injection guidance recommends layered controls, including limited tool permissions and human approval for destructive actions.
| # | Check | Why it matters | B |
|---|---|---|---|
| 29 | Are model connections and tools restricted to the minimum data and actions required? | Least privilege limits permissions even when a model follows a harmful instruction. | B |
| 30 | Have prompt-injection tests covered user input and external content, with harmful outcomes blocked? | Test attempts to redirect the model towards unauthorised data or actions. | B |
| 31 | Are daily or per-user usage limits enforced before model spending exceeds the agreed cap? | A billing alert alone does not stop additional requests. | |
| 32 | Do model requests time out and return a clear fallback when the provider fails? | Fallback behaviour tells users what happened without inventing a successful result. | |
| 33 | Are model interactions traceable without retaining unnecessary prompt or response content? | Request IDs, outcomes and redacted records may be enough for investigation. | |
| 34 | Is human approval enforced outside the model before irreversible actions? | Approval must cover the specific deletion, payment or message being executed. | |
| 35 | Is an Article 28 agreement in place when the model provider processes personal data on your behalf? | A processor agreement defines how a provider handles data for your company. |
Passing a prompt-injection test does not prove every future attack is blocked. Keep access and approval controls outside the model, and treat a missing approval check for an irreversible action as a blocker for that capability. Where a provider acts as your processor, GDPR Article 28 and the EDPB controller–processor guidance require a binding processing arrangement. If the AI output itself is the product, such as advice, scoring or diagnosis, model evaluation is also needed beyond this checklist.
Three or more “don’t know” answers mean the checklist needs technical follow-up. An AI-built product review checks the agreed areas in your codebase, with engineering and security examined together and findings prioritised in plain English.
Personal data checks under GDPR Article 25
GDPR Article 25 requires appropriate safeguards to be built into processing and only necessary personal data to be processed by default. For an AI-built product, check collection, retention and access settings before using personal data. The EDPB’s February 2026 summary explains that data protection by design and by default is a continuing duty, including for small organisations.
Six data checks supplement the 35 product checks, giving 41 rows. Apply the relevant checks whenever personal data is processed, including during development.
| ID | Personal data check | Provision |
|---|---|---|
| P1 | Do forms and data flows collect only what each stated purpose needs, with retention periods defined? | Article 25; data minimisation and storage limits. |
| P2 | Are profiles, records and sharing settings private by default where public access is unnecessary? | Article 25; privacy-friendly defaults. |
| P3 | Can the team fulfil valid deletion requests across relevant systems and explain retention exceptions? | Article 17; rights must be supported in the product. |
| P4 | Are storage locations and overseas access known, with applicable transfer arrangements assessed? | Chapter V; EU hosting alone does not settle remote access. |
| P5 | Are Article 28 agreements in place with hosting, email and AI providers acting as processors? | Article 28; assess each provider’s role. |
| P6 | Is someone assigned to assess a breach and make any required regulatory notification? | Article 33; notification timing depends on awareness and risk. |
EU hosting does not settle every transfer question. Assess overseas support access and subprocessors too. A processor agreement does not by itself resolve international transfers.
Under Article 33 and the EDPB breach guidance, notify the competent authority without undue delay and, where feasible, within 72 hours of awareness, unless the breach is unlikely to risk individuals’ rights and freedoms. The Autoriteit Persoonsgegevens is the relevant authority where the Dutch regulator is competent. Keep a named owner for that assessment. Completing these checks does not establish full GDPR compliance.
How to read your production readiness result
A production readiness result is read by unresolved conditions, not by a total score. One unresolved blocker pauses the affected launch. The three routes use this checklist’s practical rules; three unknowns is a prompt for help, not a validated risk measure.
| Your result | Route | Next action |
|---|---|---|
| Any applicable B item is no or don’t know | Fix or verify first | Pause the affected launch until the condition is demonstrated. |
| Three or more applicable answers are don’t know | Get an independent review | Use the unknowns to scope a production readiness review. |
| All applicable B items are yes and no material gap remains unresolved | Move to release planning | Review remaining issues and legal requirements, then prepare the AI deployment checklist. |
Apply the routes in order. A known blocker needs fixing even when a review is appropriate. Any unknown B item needs verification. Give non-B gaps an owner and next action; escalate confirmed exposure of sensitive data, privileged credentials or another unacceptable risk.
Before release planning, resolve applicable legal requirements and review N/A reasons. All B items answered yes means the minimum gates have evidence. Carry remaining work into the backlog with explicit ownership.
What a self-check cannot tell you
A production readiness self-check cannot establish that every relevant path has been examined. A “yes” for item 2 might cover the account screen while an export endpoint still returns another customer’s records. Someone needs to test the applicable access paths.
Founders can confirm account ownership and provider agreements; technical answers need inspection of code and deployment. OWASP A01:2025 includes access controls in unit and integration tests.
Use an independent review when important answers cannot be verified or customer requirements exceed the available evidence. Bring the completed record to help scope the unresolved areas.
How Sunbytes checks AI-built products against this list
A production readiness checklist only protects a launch when each “yes” is backed by evidence from the code and the deployment, not by memory.
Sunbytes connects the checklist to that evidence through its AI-built product review: software engineers and security specialists examine the agreed scope together, testing cross-user access, old credentials and external-service failures directly. Cybersecurity Solutions add the control layer when findings touch secrets, access rights or GDPR evidence for a customer review. When the fixes need more hands than your team has, a dedicated software development team can carry the remediation work. Together they prevent a launch from resting on answers nobody has verified.
Sunbytes is a Dutch-founded technology, cybersecurity and workforce partner, headquartered in Utrecht with a delivery hub in Ho Chi Minh City. Over 15+ years, Sunbytes has delivered 300+ projects for clients in 20 countries under an ISO/IEC 27001-certified information security management system. That certification covers Sunbytes’ own information handling; it does not certify your product. Each review is scoped around your product’s code, security, critical workflows and deployment setup, with findings and a prioritised action plan in plain English. Remediation and re-checks are scoped separately, so you can see the review cost apart from follow-up work and choose who implements the fixes.
Which of your answers are still “don’t know”? Discuss your checklist in an AI-built product review
