An AI-assisted change can look complete in a preview while leaving an important release question unanswered. Did a permissions fix change another role’s access? Does the updated checkout handle a failed payment? Can the team reverse the release without losing data?
Use this checklist after implementation and before release. It focuses on acceptance evidence for a particular change, whether your application is established or preparing for its first launch. Record passed with evidence, needs work, not applicable or not yet checked for each relevant item. Keep the working code and test the affected behavior. A release checklist is not a security certification.
1. Preserve the version that already works
Identify the currently deployed version and the candidate change in version control. Write a short acceptance statement describing the intended behavior, the affected users and the behavior that must remain unchanged. List the touched services and data structures. Preserve repeatable tests for nearby journeys, including ones the change was not intended to affect.
Ask the reviewer to connect each proposed change to a requirement or observed problem. A different framework preference is not, by itself, evidence that the existing app must be replaced. Separate urgent release issues from improvements that can follow later.
Evidence to request: the baseline and candidate versions, written acceptance criteria, a change-impact map and before-and-after regression results.
2. Test sign-in and permissions separately
Being signed in and being permitted to access a particular record are different questions. Check both. Use test accounts representing the product's actual roles: for example, a customer, a team member and an administrator. Confirm that each role can do its intended work and cannot access another customer's restricted data.
Permissions belong in the systems enforcing access, rather than only in the interface. OWASP recommends checking permissions on every request and denying access when permission has not been established. OWASP authorization guidance
Also test account recovery, sign-out and the behavior of expired sessions. Record any role or data boundary that was not examined. Avoid interpreting a successful login demonstration as a complete access-control review.
Evidence to request: a role-and-action checklist with permitted and denied cases, tested in an authorised environment against the candidate release. Repeat relevant existing checks even when the change was described as only a user-interface update.
3. Run payments through a test environment
If the change touches checkout, pricing, access entitlements or payment-related integrations, use the provider's supported testing facilities. Cover successful payment, a declined attempt, an interrupted journey and the business states relevant to refunds or subscriptions. Stripe documents test environments and test payment methods for exercising these behaviors without moving real money. Stripe testing documentation
Ask what the application treats as confirmation of payment and when it grants access or starts fulfilment. The browser returning to a success screen should not be the only evidence the team examines. Compare the provider's record with the state stored in the application.
Evidence to request: scenario results linking the test payment, the application record and the resulting access or order state.
4. Check repeated and delayed work
External events may be delivered more than once or arrive in an unexpected order. Stripe explicitly documents both possibilities. A repeated notification should not cause the same business action to be applied again inadvertently. Stripe webhook guidance
Ask the developer how the app identifies an already-handled event and distinguishes a new business action from a retry. For supported outgoing Stripe requests, idempotency keys help repeat a request without unintentionally creating the operation twice; the key must represent the intended operation consistently. Stripe idempotent requests
Evidence to request: a repeated-event test, a delayed-event test and an explanation of what happens after processing fails partway through. Include related background jobs, not only payment callbacks.
5. Identify where persistent data lives
List the databases, uploaded files and third-party records needed to run the product. Decide which data must survive a restart, republish or infrastructure change. An application can behave correctly during development while depending on storage that is unsuitable for the deployed environment.
For example, Replit's publishing guidance advises using a storage or database option rather than relying on data written to a published app's filesystem. Check the rules for the actual deployment you use. Replit publishing documentation
Evidence to request: a data-location inventory, persistence checks and a clear distinction between temporary files and durable records.
6. Demonstrate recovery before you need it
For a release that changes stored data or its structure, ask what is backed up, how often, where the backup is stored and who can restore it. A repository backup does not establish that application records or uploaded files can be recovered. The recovery plan needs to match the systems containing those assets.
PostgreSQL, for example, documents several backup approaches with different operating characteristics. The appropriate approach depends on the application and recovery requirements. PostgreSQL backup and restore
Run an agreed restore exercise in an isolated environment where feasible. Record the backup used, the restored data checked and any gaps. Decide what amount of data loss and recovery time the business can tolerate before accepting the release.
Evidence to request: a recovery procedure and the result of a representative restore test.
7. Review the deployed app as its own environment
Confirm production settings, service connections and the release version. Review configuration and dependency changes alongside the code diff; these can alter behavior even when the visible feature change is small. Check that test data and test integrations are not confused with live ones. Exercise the critical journeys against the release candidate, with appropriate controls for any operation that could affect real users.
Write down how to reverse an unsuccessful release. Code rollback and database recovery are separate questions: returning to an older application version may not undo a data migration. Decide how a failed migration or incompatible change would be handled before running it.
Evidence to request: deployment instructions, environment checks, release tests and a recovery decision for database changes.
8. Make ownership and ongoing operation practical
Identify who controls the repository, hosting, domain, database and external-service accounts. Confirm that the business has the access it needs and that more than one authorised person understands the handover. Keep credentials out of project briefs and ordinary chat messages.
Ask another developer to follow the setup instructions. Can they run the app, execute the checks and find the deployment procedure? Record dependencies and licences requiring attention rather than assuming every generated asset can be used without review.
Finally, define who notices failed jobs, unexpected errors or a broken critical journey. Agree the response process and the boundaries of any support arrangement.
Turn the checklist into a release decision
Summarise the evidence, unresolved blockers and accepted limitations for this candidate version. Give each open issue an owner and a next step. If a check has not run, retain that uncertainty instead of calling it passed. After deployment, repeat the agreed smoke checks and compare the running version with the candidate that was tested. Stop or reverse the release according to the agreed plan if a critical acceptance check fails.
For help examining the existing implementation, request a scoped code review. If the project needs hands-on completion after review, see vibe coding to production.