Treat an AI-generated codebase as an unfamiliar system, not a verdict on its author. The takeover job is to find what the app does, what it owns, where it can fail and who will maintain it. A folder full of generated code does not by itself prove insecurity or make a rewrite worthwhile.
Ask the outgoing owner for a working walkthrough and written handoff. Keep the initial review read-only where possible. Do not change production credentials, delete data or rewrite the app while you are still discovering its dependencies.
Establish ownership and a reproducible setup
Confirm the repository, hosting, domain, database, payment and email accounts. Record who can grant access and who pays each bill. Transfer secrets through an approved secure route, not a README or chat transcript.
Run the app from its documented setup in a suitable development environment. Compare the required runtime and build scripts with the actual manifest and deployment configuration. If setup fails, record the exact missing input rather than adding guesses to production.
| Handoff artifact | What to verify |
|---|---|
| Repository and branch | Which commit is deployed and how a change reaches production |
| Setup instructions | A clean environment can start and build the app |
| Configuration inventory | Required names, purpose and secure storage, without secret values |
| Data and integrations | Ownership, access scope and recovery route |
| Critical-flow tests | What proves login, checkout and fulfillment work |
| Incident and risk log | Known failures, current workaround and responsible owner |
Keep this map small enough to stay current. A diagram is useful if it reflects the deployed system, not a generated architecture wish list.
Trace the app's critical paths
Choose the workflows that create the most harm if wrong. For a store, trace account access, product selection, price calculation, payment, order creation and fulfillment. Identify the browser, server, database and external service involved at each step.
Record where input is validated and where permissions are enforced. A hidden button is not an access-control boundary. Test signed-out access and two users attempting to access each other's records in an authorized test environment.
Review dependencies and secrets separately
Read the package manifest and lock file. Use the project's supported dependency checks and review findings against the actual deployed versions. GitHub's dependency review documentation explains how dependency changes can expose security and license risk; feature availability varies by repository and plan.
A scan finding is a lead to investigate, not permission to upgrade every package at once. Record the affected package, whether it is used, proposed fix and regression test. Check secrets and authorization separately. If a live secret was exposed, arrange rotation with its owner; removing a string from one file does not invalidate the credential.
Test transactions and recovery
For Stripe Checkout, compare the implementation with Stripe's fulfillment guidance. Confirm server-side event handling and duplicate-event behavior. Do not rely on the browser's success screen as the only evidence an order was created.
Run agreed test cases for payment failure, refund, out-of-stock products and downstream service failure. Keep live spending outside a development test. Verify the team's backup and restore route without overwriting production. A backup that nobody can restore is an untested recovery claim.
Turn findings into a prioritized change list
Separate an observed defect from a suspected weakness. Write the reproduction, business impact, affected component and a test that would show it is fixed. Prioritize exposed data and incorrect transactions before cosmetic duplication.
Avoid invented grades such as 'production-ready: 92%'. A useful handoff names unresolved risks and their owners. For example: 'Duplicate payment event creates two fulfillment jobs; reproduction saved; fix requires idempotency test.' That is actionable without pretending a score captures the system.
Make the first change small and reversible
Choose one high-impact defect. Add a regression test, change the narrowest responsible component and review the diff with someone who understands the workflow. Deploy through the normal review process and watch the relevant error or business state.
Do not bundle a framework upgrade, database change and checkout rewrite into the first fix. If a larger replacement is needed, explain what cannot be preserved and how rollback would work before estimating it.
For a Bolt-built store's symptoms, use the troubleshooting checklist. If the business wants a standard hosted store, compare the Shopify migration steps and budget worksheet. A scoped code rescue review can support the handoff; it does not replace your own access and transaction tests.