The first thing a production readiness checklist should settle is one question: can a signed-in user read another customer’s rows? This list has 123 items across 13 areas, each with the reason it matters and the test that proves it is done, written for one app on managed hosting rather than a platform team.
What this checklist is, and who it is for
A production readiness checklist is the list of conditions that must be true before strangers depend on your app, each with a test that proves it. This one has 123 items in 13 areas and is written for a single app on managed hosting, not for a platform team.
It is written for a founder, or the CTO or agency helping one, with a working app on Vercel, Supabase, Railway, Render or Fly and nobody on call overnight. Distributed tracing, autoscaling policies and chaos testing are left out on purpose: in my reading they are platform-team work, and one app with one database gets more from the rows below.
This page leaves the definition of production ready, and the question of whether AI can write code that meets it, to a separate piece on what production ready means. Here the job is narrower: every item, why it matters, and how you would check it.
Checklist or review: which one a small team needs first
The checklist and the review are different things: the checklist is the list of conditions with a test each, and the review is the meeting or gate where someone reads the evidence the list produced. A one- or two-person team needs the list first.
A review with no list behind it has nothing to read. Once a second engineer, an investor’s advisor or a customer’s security team wants to sign off, the gate and the questions asked at it become the production readiness review, which has a format of its own.
How to use this list if you are one person, or two
Run the list in five passes: who can access the data, secrets, money, knowing when it breaks, and getting back after a bad release. Those five passes cover 13 of the 123 items. An item counts as done when its test has run and the result is written down.
When there are only one or two of you, checking whether your app is production ready starts with that order. It is the answer I would give to a Reddit post asking what to check before launching an app: start where a mistake costs a customer their data or their money, and leave the tidy extras for later.
- 01 Who can access the data: server-side authorization, data isolation across every table, and verified backups with a real restore.
- 02 Secrets: frontend secret removal, a repository history scan with rotation of anything exposed, and administrative keys kept on the server only.
- 03 Money: webhook signature verification, idempotent webhook handling, and entitlements checked on the server.
- 04 Knowing when it breaks: error tracking and uptime monitoring.
- 05 Getting back: a tested rollback and a disaster recovery drill.
The test for each step is the verify line of that item in the tables below: the access and secrets passes live in areas 1, 2 and 4, money in area 5, alerts in areas 6 and 8, and recovery in areas 4 and 7. After the five passes, work through the rest area by area.
My working rule for the whole list: an item is finished when someone can point to the test run and its recorded result, and the code merely existing does not count. The case I keep in mind is GitLab’s own postmortem of its 2017 database outage, which describes backups that were supposed to exist and were not there when they were needed, and it is why backup testing belongs on the data consistency checklist for SaaS. The lesson I take from it is that a check on paper counts for nothing until its test has run, which is why every row here ends in a test.
Access and alerts come first for a reason. Of the 21 third-party apps I audited in June and July 2026, 9 had row-level security gaps and 17 had no error tracking or alerting: when a user hits an error, nothing records it. Those 21 were a selected set of apps, not a random sample, so the numbers explain the order rather than giving a rate for all AI-built apps; the full ranking of where AI-built apps fail most is a subject of its own.
My rule for an app ready for paying customers: at least the first three passes before the first charge goes through. If you are doing this alone and part time, I’d plan for weeks rather than days to get through the whole list. The same order holds for a side project: before you can say “I am ready for production”, all five passes should have run with their results on record.
If the app came out of a builder, the platform-specific passes are covered in is a Lovable app production ready and in Bolt.new production readiness. If you would rather pay someone, what it costs to make an app production ready sets out what sellers charge for a professional pass.
The production readiness checklist, by area
The list below is a production readiness checklist for web apps run by a small team: 13 areas, 123 items, and every row gives the item, why it matters and how to verify it. Taken together, the tables are the production ready checklist for one web app in full, written so you can run it. Areas 6 to 8 are the operational readiness part, the IT side of the checklist a SaaS needs once real users arrive: errors, releases and alerts. The other ten areas make up the rest of a software production readiness checklist: who gets in, what stays secret, what the data and money do, and what the next engineer inherits.
1. Authentication and authorization (11 items)
| Item | Why it matters | How to verify |
|---|---|---|
| Complete authentication flow review | Broken account flows can lock out customers or allow unauthorized access. | Exercise successful, rejected, expired, and reused-token paths for each supported flow. |
| Session and token controls | An old session can remain usable after an account owner tries to secure it. | Confirm expired and revoked sessions cannot continue accessing protected resources. |
| Server-side authorization | A hidden button does not prevent a direct request to the backend. | Call protected actions directly as unauthorized and underprivileged users; confirm rejection. |
| Data isolation across every table | Missing data boundaries can expose one customer’s records to another. | Run read and write tests as anonymous users, different roles, and separate tenants. |
| Protected administrative actions | Unprotected administrative actions can let ordinary accounts change or delete important data. | Test administrative operations using both authorized and ordinary accounts. |
| Authentication abuse protection | Automated login attempts can compromise accounts or overwhelm account services. | Simulate repeated attempts and verify limits, responses, and normal-user recovery. |
| Documented role model | Ambiguous permissions create inconsistent behavior as the product grows. | Compare the role matrix with tested backend permissions. |
| Complete account deletion | Removing a profile alone can leave personal data scattered through the system. | Delete a seeded account and inspect its related records, files, and recorded retention exceptions. |
| Session management and global sign-out | Users need a way to remove access from lost devices or unfamiliar sessions. | Create multiple sessions, revoke them, and confirm protected access stops. |
| Sensitive-action audit log | Important changes are difficult to investigate without a reliable activity record. | Trigger the listed actions and verify accurate, access-controlled audit entries. |
| Two-factor authentication for owner and admin accounts | One leaked password on a dashboard account is a full takeover of the product and its data. | Attempt sign-in to each owner and admin account without the second factor and confirm it is refused. |
On an app with more than one role, each row above grows into a fuller authentication checklist, with one test per role for every protected action.
2. Secrets, keys and configuration (9 items)
| Item | Why it matters | How to verify |
|---|---|---|
| Frontend secret removal | Exposed private credentials can let others access services using your permissions. | Scan source and built assets and inspect browser traffic for private credentials. |
| Repository history scan and rotation | Deleting a secret from the latest commit leaves earlier copies accessible. | Retain scan results and confirm exposed credentials have been invalidated and replacements work. |
| Server-only administrative keys | Administrative keys can bypass the data protections intended for ordinary users. | Check runtime configuration, built assets, and each code path using administrative credentials. |
| Environment configuration separation | Testing with live credentials can affect real customer data and transactions. | Inspect environment mappings and confirm staging actions stay within staging services. |
| Protected third-party API usage | Abused endpoints can consume paid services on your account. | Test unauthorized calls, per-user limits, and configured usage ceilings. |
| Secret rotation runbook | An urgent rotation becomes harder when nobody knows which services depend on a key. | Rehearse rotation with a test credential and record the affected services and checks. |
| Metered-service spend alerts | Unexpected consumption can continue unnoticed until the next invoice. | Trigger a test threshold and confirm the alert reaches the designated owner. |
| Provider account ownership | AI-built apps are often wired to accounts the builder created. The business does not control what it does not own. | Produce an inventory listing each provider, the owning account, the owner role holder, and the date the previous builder’s access was removed. |
| Managed-platform security settings | Managed platforms ship permissive defaults so that prototypes work. Those defaults are what leaks data in production. | Record the before-and-after settings for each managed service, naming each risky default and its new value. |
Rotation, spend alerts and account ownership are the quieter rows here, and they are where secrets management best practices go beyond keeping keys out of the code.
3. Input, output and application security (12 items)
| Item | Why it matters | How to verify |
|---|---|---|
| Server-side request validation | Malformed or hostile inputs can corrupt records or reach other users’ screens. | Submit invalid and hostile payloads and confirm safe rejection or handling. |
| Secure file uploads | Weak upload and storage controls can expose documents or accept unsafe files. | Test disallowed formats, oversized files, unauthorized downloads, and storage listings. |
| Restricted cross-origin access | Overly permissive cross-origin access can expose authenticated responses to untrusted websites. | Test approved and unapproved origins, credential handling, and state-changing request protections. |
| Production security headers | Missing browser protections can increase exposure to script injection, framing attacks, or insecure connections. | Inspect response headers and exercise the application to confirm intended protections without broken flows. |
| Dependency remediation | Published package vulnerabilities can remain reachable in an otherwise functional product. | Record the dependency scan, remediation, and regression checks after changes. |
| Public-endpoint rate limits | Abuse can create spam, availability problems, and unexpected service bills. | Simulate bursts and verify enforcement without blocking ordinary use. |
| OWASP Top 10 review | Unexamined application risks leave preventable weaknesses in the production foundation. | Deliver category-level results and supporting test evidence, with justified non-applicable cases identified. |
| Bot protection | Automated submissions can pollute accounts, reporting, and outbound communication. | Confirm valid users can submit and rejected or missing bot challenges are handled safely. |
| Security disclosure contact | A researcher needs a clear way to report an issue to the right person. | Check the published file, contact details, and delivery of a test message. |
| Targeted external penetration testing of the five highest-risk surfaces | Implementation review alone may miss behavior exposed through real attack paths. | Record the five surfaces, authorized tests, findings, fixes, and retest outcomes. |
| AI feature hardening | Model calls are a new input surface. Unbounded ones leak data, run up bills, and fail loudly when the provider does. | Run injection test cases against each feature, a spend simulation that hits the limit, and a provider-outage simulation in staging. |
| Edge protection | Application-layer bot protection never sees a volumetric flood; it takes the app down first. | Send a load burst at the edge and confirm it is absorbed while the origin’s health endpoint stays green. |
An HTTPS checklist for an app comes down to two rows: the security headers in this table and the domain, DNS and TLS row in area 7. The rest of the table is the application layer of web app security.
4. Database and data (14 items)
| Item | Why it matters | How to verify |
|---|---|---|
| Schema integrity review | Inconsistent relationships create broken workflows and unreliable reports. | Test rejected invalid records and expected relationship behavior using representative data. |
| Foreign-key and query indexing | Missing useful indexes can make ordinary requests expensive as data grows. | Retain before-and-after query plans and timings; document the index decisions. |
| N+1 query removal | Fetching a list can create unnecessary database traffic and slow responses. | Measure database query counts for representative list and detail views. |
| Atomic multi-step writes | A partial operation can leave users, orders, or workspaces in inconsistent states. | Inject a failure between writes and verify atomic rollback or the documented recovery behavior. |
| Connection pooling | Connection exhaustion can make the database unavailable during busy periods. | Run concurrent requests and record connection usage, errors, and pool configuration. |
| Version-controlled migrations | Untracked dashboard changes make environments difficult to reproduce and maintain. | Apply the migration sequence to a clean test database and compare the resulting schema. |
| Verified backups and restore | A backup only helps if it exists and can be restored successfully. | Restore a backup into an isolated environment and check representative data integrity. |
| Consistent time handling | Inconsistent time handling can distort billing schedules, reporting, and user expectations. | Test timestamps across time zones and relevant date boundaries. |
| Recoverable deletion | Accidental deletion should be recoverable where the business workflow requires it. | Delete and restore a test entity and verify normal queries exclude deleted records. |
| Staging seed data | An empty staging system gives the team little opportunity to test realistic workflows. | Run the seed process on a clean staging database and exercise core flows. |
| Orphaned-record cleanup | Unnecessary data complicates exports, reporting, maintenance, and storage. | Run a dry-run comparison and confirm the cleanup preserves valid linked records. |
| Disaster recovery drill | Your team needs evidence of recovery time before a real incident. | Record the timed drill, recovered services, integrity checks, and observed recovery limits. |
| Data model diagram | Technical reviewers and future engineers need a quick way to understand the data. | Compare the diagram against the delivered schema and migrations. |
| File storage lifecycle | File buckets are the most common place an AI-built app is publicly readable without anyone noticing. | Fetch a private file without a signed link and confirm refusal; upload an oversized and a disallowed file and confirm rejection. Upload a safe malware-scanner test file and confirm rejection. Verify that expired uploads are removed according to the configured retention rule. |
On Supabase, the isolation row from area 1 comes down to row-level security, the subject of Supabase RLS best practices. For the backup row, Supabase says it backs up “all Pro, Team, and Enterprise Plan projects on a daily basis” and recommends “that free tier plan projects regularly export their data using the Supabase CLI db dump command” , so on the free tier, in my reading, the restore test starts from your own export and restores into a scratch project, never over the live one. Restores and recovery drills are where data consistency work for a SaaS starts.
5. Payments and billing (10 items)
| Item | Why it matters | How to verify |
|---|---|---|
| Webhook signature verification | Forged events can wrongly grant paid access or change account state. | Confirm valid events succeed and invalid or altered payloads are rejected. |
| Idempotent webhook handling | Repeated events can duplicate fulfillment or corrupt subscription state if processed unsafely. | Replay and concurrently deliver events; confirm one intended business effect. |
| Complete billing event lifecycle | Missing lifecycle handling can leave paid access inconsistent with billing. | Test the relevant lifecycle transitions and verify the final account state. |
| Server-side entitlements | Client-side plan labels alone do not protect paid functionality. | Attempt paid operations with free, expired, and valid paid accounts. |
| Separated payment environments | Misconfigured environments can process real charges during testing or accept no real payments in production. | Inspect provider accounts and run isolated test-mode transactions. |
| Billing reconciliation check | Undetected drift creates access and revenue-reporting inconsistencies. | Seed mismatched records and verify they are identified and reconciled correctly. |
| Failed-payment recovery | Payment failures need a clear recovery path for customers and predictable access behavior. | Simulate payment failure, notice delivery, recovery, and grace-period expiry. |
| Customer billing portal | Routine billing changes otherwise require manual support. | Test an authenticated customer’s portal access and resulting updates in the application. |
| Scheduled reconciliation | A one-time check will not catch drift introduced after future changes. | Execute the scheduled job against test mismatches and verify its alert and output. |
| Billing operations runbook | The team needs clear procedures when a billing question becomes urgent. | Walk through the procedures in test mode and identify the responsible account permissions. |
If you bill through Stripe, run the provider side of these rows against the Stripe go-live checklist; the billing logic behind them follows SaaS billing process best practices.
6. Error handling and reliability (10 items)
| Item | Why it matters | How to verify |
|---|---|---|
| Consistent exception handling | Silent failures can make an unsuccessful operation look complete. | Inject failures and verify accurate responses and diagnostic records. |
| Backend handlers and frontend boundaries | A localized failure should not leave the customer with an unexplained blank page. | Trigger server and component errors and confirm safe responses and contained UI failures. |
| Error tracking | Customer complaints should not be the only way you discover application faults. | Send a test error and verify symbolication, environment attribution, and alert delivery. |
| External-call timeouts | Slow providers can leave requests and workers waiting indefinitely. | Simulate a slow dependency and confirm bounded waits and a useful failure state. |
| Retries with backoff | Temporary failures need recovery without creating duplicate actions or retry storms. | Simulate transient and persistent failures and verify retry limits and side effects. |
| Background processing | Lengthy work can exceed request limits or be interrupted when a browser disconnects. | Run a long task beyond the normal request window and verify completion and user-visible status. |
| Reliable job execution | Retries can duplicate actions, while discarded failures leave work unfinished. | Replay jobs, exhaust retries, and verify one intended result plus a recoverable failure record. |
| Graceful degradation | One provider outage should not unnecessarily block the entire application. | Disable an integration and check its fallback plus unaffected customer journeys. |
| Health endpoint | Monitoring needs a reliable signal for whether the application can serve requests. | Check healthy and degraded responses and confirm sensitive details are not public. |
| Staging outage simulation | Fallback code needs to be exercised before customers depend on it. | Record outage scenarios, queue behavior, customer messages, and recovery results. |
Timeouts, retries and fallbacks, tested in staging before a real outage tests them, are what hardening SaaS applications for resilience means for one app.
7. Environments, CI/CD and deployment (13 items)
| Item | Why it matters | How to verify |
|---|---|---|
| Three isolated environments | Routine tests should not change real customer records or trigger live transactions. | Verify service isolation and perform a staging action without a production side effect. |
| Protected production branch | Unchecked changes can otherwise bypass the release process. | Attempt a failing merge and confirm the protection prevents it. |
| Pull-request CI | Automated checks catch regressions before changes reach customers. | Submit failing and passing changes and retain the CI results. |
| Staging deployment and production promotion | A repeatable release path removes reliance on one person’s manual routine. | Deploy a change to staging, then demonstrate the production promotion gate. |
| Migration-aware deployment | Application code can fail when its expected schema is missing or incompatible. | Deploy a representative schema change and verify sequencing and failure handling. |
| Tested rollback | A failed release needs a recovery path the team has already practiced. | Roll back a test release and verify application behavior and retained data. |
| Pull-request previews | Reviewers need to inspect a change before it joins the release branch. | Open a preview from a test pull request and verify its environment isolation. |
| Contribution guide and PR template | Consistent review information makes future development easier to assess. | Create a pull request using the template and follow the guide on a clean checkout. |
| Automated dependency updates | Routine security and maintenance updates need a repeatable path to review. | Verify a proposed update triggers the appropriate CI checks and review requirements. |
| Timed deployment | A slow release process delays delivery of urgent fixes. | Time the agreed deployment path and record its start, finish, and included steps. |
| Independent repository and hosting | An app that only exists inside the builder tool cannot be reviewed, rolled back, or handed to another engineer. | Deploy a fresh clone to staging through the pipeline with no step that depends on the generating tool. |
| Feature flags and kill switches | The fastest fix for a broken release is switching the feature off. | Disable a flagged feature in production and confirm the product stays usable with the feature hidden. |
| Domain, DNS and TLS hygiene | An expired domain or a misissued certificate is an outage no code fix repairs. | Pass an external TLS scan at the top grade and file a DNS record export in the runbooks. |
On AWS, as I read it, the rows are the same and only the service names change, so this table doubles as an AWS production readiness checklist. One plan condition matters for the protected-branch row: GitHub says protected branches are available “in public repositories with GitHub Free and GitHub Free for organizations” and “also available in public and private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server”, and rulesets “in public and private repositories with GitHub Pro, GitHub Team, and GitHub Enterprise Cloud”. On a GitHub Free private repository, then, that row’s test needs a paid plan or a gate on the hosting side, in my reading. The rest of this table is DevOps for startups at its smallest useful size.
8. Logging, monitoring and alerting (8 items)
| Item | Why it matters | How to verify |
|---|---|---|
| Structured, sanitized logs | Useful traces need to support investigation without creating another data leak. | Trace a test request across services and check log content for sensitive fields. |
| Uptime monitoring | A public outage can go unnoticed without independent checks. | Trigger a controlled check failure and verify notification and recovery reporting. |
| Operational threshold alerts | Gradual degradation needs attention before it becomes a broad outage. | Trigger each configured condition and record its alert threshold and behavior. |
| Actionable alert routing | An alert is only useful if the responsible person sees and understands it. | Send test alerts and verify their destination, context, and response instructions. |
| Log retention | Retention that is too short impairs investigation; uncontrolled retention increases cost and exposure. | Inspect the configured windows and verify retention behavior in supported systems. |
| Core product analytics | The team needs to see where customers progress or encounter friction. | Run core journeys and verify event names, properties, and consent behavior. |
| Public status page | Customers need a central place to understand an interruption. | Publish a test incident and verify the page remains reachable separately from the app. |
| Unified operations dashboard | Checking the health of the business should not require piecing together several tools. | Compare the displayed metrics with their source systems and verify refresh behavior. |
Of everything in logging and monitoring, uptime checks and alert routing are the two rows I would run first, because an alert nobody receives changes nothing.
9. Performance (7 items)
| Item | Why it matters | How to verify |
|---|---|---|
| Appropriate caching | Repeated expensive work wastes resources; unsafe caches can expose stale or private data. | Compare cache hits and misses, test invalidation, and verify tenant separation. |
| Load test and bottleneck fixes | Launch capacity should be measured before real traffic becomes the test. | Report the workload, duration, environment, concurrency, latency, and error rate before and after changes. |
| Bundle optimization and lazy loading | Large initial downloads slow first use, especially on constrained devices. | Compare built bundle sizes and test route loading with representative network conditions. |
| Image optimization | Oversized assets waste bandwidth and slow customer-facing pages. | Compare transferred sizes and inspect rendered images at intended display dimensions. |
| Lighthouse performance review | Slow or difficult-to-use pages create avoidable friction. | Report the chosen pages, device profile, numerical targets, and final results; check key accessibility interactions yourself. |
| Written capacity statement | A number without its conditions is a poor basis for growth decisions. | Link capacity claims to load-test evidence and identify untested projections as projections. |
| Accessibility baseline | Enterprise and public-sector buyers require it, and generated interfaces fail it by default. | Score 100 on an automated accessibility audit of the core pages and complete a keyboard-only walk through signup, checkout, and the main task. |
Measure before tuning: the load test row gives every other change in web performance optimization a baseline to beat.
10. Code health and AI development guardrails (11 items)
| Item | Why it matters | How to verify |
|---|---|---|
| Dead code and duplicate logic cleanup | Repeated implementations make it easy to fix one path and leave another broken. | Record removed or consolidated code and run regression checks on affected flows. |
| Consistent state management | Competing sources of truth can show different values in different screens. | Exercise refreshes, mutations, and navigation and verify consistent displayed and stored state. |
| Typed API boundaries | Uncoordinated schema changes can break clients silently. | Introduce a deliberate contract mismatch and confirm type or contract checks catch it. |
| Documented repository structure | Future developers and AI tools need to know where responsibilities belong. | Follow the README from a clean checkout and trace a core feature through its documented modules. |
| Critical-path smoke tests | A small change can break a business-critical journey elsewhere. | Run the suite in CI and demonstrate that an intentional regression fails it. |
| Strict typing | Stronger checks catch classes of mistakes before execution. | Record the strict configuration and a clean checking run without suppressing the errors being fixed. |
| Auth and billing unit tests | Sensitive decisions need a reliable safety net when the implementation changes. | Run the tests and show rejection of unauthorized access and incorrect billing transitions. |
| AI repository guardrails | Future AI-assisted changes can undo hardening unless the workflow checks them. | Review the guidance and demonstrate CI catching a representative forbidden regression. |
| Recorded codebase tour | A future engineer should not have to rediscover the system from scratch. | Deliver an accessible recording with chapter markers or a short contents list. |
| Reproducible local development setup | The next engineer’s first hour decides whether they can work on the product at all. Generated apps rarely have this. | Go from clone to running application on a new machine by following the guide alone. |
| Open-source license audit | License questions are on every technical due diligence list, and generated apps pull packages without checking. | Include the license report in the due diligence pack with zero unresolved flags. |
The guardrails row matters most while the app is still built with AI tools, and it is one part of engineering standards for AI-assisted teams.
11. Email and communications (3 items)
| Item | Why it matters | How to verify |
|---|---|---|
| Sending-domain authentication | Domain-authentication problems can undermine legitimate email delivery. | Inspect DNS and received message headers for the configured authentication results. |
| Transactional delivery tracking | Untracked failures make it difficult to know whether a customer received a critical message. | Trigger each critical message type and confirm provider records and expected recipient delivery. |
| Bounce and complaint handling | Repeated sending to invalid or complaining recipients can damage sending reputation. | Simulate provider events and verify suppression and subsequent send behavior. |
It is a short area, but a password-reset email that lands in spam locks a customer out as surely as a bug does, which is why knowing how to improve email deliverability belongs on a launch list.
12. Privacy and compliance foundations (8 items)
| Item | Why it matters | How to verify |
|---|---|---|
| Personal-data inventory | The team needs a reliable record when a customer or reviewer asks about data use. | Trace a sample user through storage, logs, and providers and compare it with the inventory. |
| Data export and deletion paths | Personal-data requests are difficult to fulfill when the application has no reliable mechanism. | Export and delete a seeded user’s data; verify completeness, authorization, and recorded exceptions. |
| Privacy and terms alignment | The public description of data use should match what the product actually does. | Compare the policy statements with the data inventory and provider flows and record the owner-approved alignment. |
| Cookie consent controls | Optional tracking needs to follow the user’s recorded consent choices. | Test consent, refusal, withdrawal, and persistence; verify optional scripts respect those choices. |
| Data retention policy | Keeping data without a defined purpose makes storage and data handling harder to govern. | Review the schedule against the data inventory and the configured lifecycle controls. |
| SOC 2-style controls checklist | Enterprise buyers need evidence of how the application is protected and operated. | Link each documented control to its owner, configuration, or test evidence. This checklist is not a SOC 2 audit report. |
| Personal data sent to model providers | For an AI app, the model provider is a second place customer data lives. | Trace each model call, list the fields sent, and match them against the inventory. |
| Subprocessor list | Every business customer’s security questionnaire asks for it, and reviewers cross-check it against the privacy policy. | Confirm the list matches the provider inventory and the privacy policy. |
These rows are technical controls; how to manage SaaS data compliance as a whole also involves policy and legal questions a technical checklist does not answer.
13. Handover and documentation (7 items)
| Item | Why it matters | How to verify |
|---|---|---|
| Production readiness report | Engineering work needs a record your team and reviewers can inspect. | Account for every item on the list; keep failures visible until resolved and explain genuine non-applicable items. |
| System architecture diagram | New engineers and reviewers need to understand how the application fits together. | Compare the diagram with the delivered environment and repository. |
| Operating runbooks | The team needs usable procedures when an incident or release requires action. | Walk through the runbooks against the delivered configuration and reference the rehearsal evidence. |
| Live technical handover | Documentation is more useful when the team can ask questions about operating the system. | Deliver the recording, supporting documents, and answers or follow-ups from the session. |
| A defect-fix window after handover | Issues discovered just after delivery need a clear route back to the team. | Record the coverage dates, reporting channel, reproduction details, fixes, and retest results. |
| Technical due diligence pack | Technical reviewers need an organized evidence pack rather than scattered files. | Check the pack for completeness, consistent version references, and readable linked evidence. |
| A window for questions after handover | Small questions often arise when the client starts using the handover independently. | Provide the channel, access instructions, and the start and end dates in the handover. |
These rows are what the next engineer or reviewer reads first, and three of them go deeper as topics of their own: what a developer handoff looks like, technical documentation for investors and the runbook template.
What to check before launch, in one screen
This block is the whole list in short form: one line per area, naming the single item I would run first in it. It is also the production readiness checklist template for your tracker, with nothing to download; copy it, then add a result, the evidence and a date to each line.
- Authentication and authorization: data isolation across every table.
- Secrets, keys and configuration: frontend secret removal.
- Input, output and application security: server-side request validation.
- Database and data: verified backups and a restore test.
- Payments and billing: webhook signature verification.
- Error handling and reliability: error tracking.
- Environments, CI/CD and deployment: tested rollback.
- Logging, monitoring and alerting: uptime monitoring.
- Performance: a load test with the first bottleneck fixed.
- Code health and AI development guardrails: critical-path smoke tests.
- Email and communications: sending-domain authentication.
- Privacy and compliance foundations: a personal-data inventory.
- Handover and documentation: a readiness record with every result on it.
Every line points back to its area table, where the verify step sits, so when time is short the block still tells you what to check before launching a web app. The best pre-launch checklist for a web app is one where each line leads to a test, so treat this block as an index to the tables, never a replacement for them. Before releasing a webapp, run this checklist’s thirteen lines, record what happened, then go back through the full tables.
A pre-launch and post-launch checklist divides along one line: before launch you prove the controls work, and after launch you watch them. The post-launch half, support and the first weeks of monitoring, is a separate checklist. For the day of the switch itself, a go live checklist is the short version to keep open.
How to record the result so someone else can trust it
A readiness record is one row per item: the result, the evidence and the date. Failures stay on the list until they are resolved, and every item marked not applicable carries a written reason, so a reviewer can check the record instead of taking your word for it.
The record has four columns: item, result, evidence, date. This record is the production readiness document a reviewer, an investor or a client asks for, and its rows are your production readiness criteria written down as tests that ran. The three rows below are illustrative, for a small SaaS on Supabase and Stripe, stated as assumptions: not a real app and not an audit.
| Item | Result | Evidence | Date |
|---|---|---|---|
| Data isolation across every table | Pass | A second test account’s reads of the first account’s records returned no rows, its writes changed none, and the targeted rows were intact afterwards | YYYY-MM-DD |
| Webhook signature verification | Pass | An altered test event was rejected | YYYY-MM-DD |
| Tested rollback | Not yet run: open | None yet | Left blank until it runs |
The first row is worded that way because of how Supabase refuses. Supabase says “Think of a policy as adding a WHERE clause to every query”, and a policy’s using clause that filters a row out “raises nothing, matches zero rows”; its own policy tests warn that “Matching no rows is not proof on its own. Pair every denied write with a check that the row it targeted is intact.” An empty result alone could mean the policy worked or that the test account never had matching rows.
The third row is the point of the format. The production readiness report row in the area 13 table asks for exactly this: failures stay visible until they are resolved. For an investor, the same record becomes the core of the technical documentation they read before a round.
Where the sprint does this
Anyone who can make an app production ready should be able to show you this list with a result against every row. The Production Hardening Sprint’s published scope is this same list, 123 deliverables across 13 engineering areas , and it runs for 10 working days ; its production readiness report accounts for all 123 IDs, keeps failures visible until resolved and explains genuine non-applicable items, the record described above. Formal third-party certifications and independent audit opinions are separate from these engineering deliverables , and legal advice and certification are separate services. Each item, with what we do and how we verify it, is in the sprint’s published scope.
Common questions about production readiness
What is an operational readiness checklist?
An operational readiness checklist covers running the app rather than building it: what happens when code fails, how a release ships and comes back out, and how you learn that something broke. In this list that is the error handling, deployment and monitoring tables, 31 items between them.
How to measure operational readiness?
Measure it by running the verify line of every operational item and counting the results: passed, failed, and not yet run. A count of passed items out of the 31 in the error handling, deployment and monitoring tables, with every open item named, tells you more than a percentage score, because each open item has a next step.
What are the steps involved in a pre-production checklist?
Five steps, in this order: lock down who can reach each customer’s data, get secrets out of the browser and the repository, make payment events trustworthy, make failures visible to you, and prove you can return to the last good release. After that, work through the remaining items area by area and write down each result.
How to make a Spring Boot application production ready?
The same way as any other app: the checklist does not change with the framework, only the tools that satisfy each row. React and Angular apps take the same rows too.
For Spring Boot, the tools start with Spring Boot’s production-ready features. The documentation says “Spring Boot includes a number of additional features to help you monitor and manage your application when you push it to production.” and “Auditing, health, and metrics gathering can also be automatically applied to your application.” Its actuator endpoints include health and metrics , which serve the health endpoint row in the error handling table and the monitoring rows after it.
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