Implementation worksheet · 6 min read
A Technical Handoff Checklist for Acquiring an AI-Built App
Treat acquiring an AI-built app as a transfer of control over every account the app depends on, verified by the buyer, rather than a download of code. List every asset: the builder project, the code export or repository, the domain and DNS, the database and its backups, file storage, the email-sending domain, the payment processor, OAuth app registrations, every third-party API key, analytics, and the admin accounts inside the app. For each one the seller starts the transfer, the buyer proves control by making a harmless change, and only then is every secret the seller knew rotated. Remove the seller's access at close and agree a support window in which they answer questions without holding access.
Scope: the actor is a buyer, with whoever reviews the technical side for them, acquiring a small AI-built app through a marketplace or a private deal. The starting state is agreed terms, before closing. The boundary is technical control of assets; contracts, intellectual property, tax and data-protection obligations belong with the buyer's legal and financial advisers. The outcome is a checklist with the seller action, buyer verification and status for every asset, plus a log of rotated secrets.
Put it into practice
1. Inventory every account the app touches
Ask the seller for a list, then check it independently. DNS records show which email and verification services are in use; the app's configuration (environment variables or the builder's secrets settings) lists the services it calls; receipts and outgoing emails show the providers. The asset nobody listed is the one that breaks after close.
2. Transfer ownership, not passwords
A shared login to the seller's account isn't a transfer, because the seller can still reset it. For each service, use its own ownership-transfer or team-invite process, or create the account under the buyer and re-point the app. Check each provider's documentation for how ownership changes, the builder platform's included, rather than assuming it works like another provider's.
3. Prove control with a harmless change
For each asset, the buyer makes a small, reversible change from their own account: add a DNS TXT record and see it resolve, create a test API key, invite a test admin. Seeing a dashboard isn't control; being able to change something is.
4. Get the code and data in a form you can run
If the deal allows, run a code export acceptance test before close: fresh clone, install from the lockfile, build, run against a database you own, deploy somewhere the seller doesn't control. Take a full database backup and restore it to a buyer-owned environment.
5. Plan the payment processor early
A payment account belongs to the business entity that holds it, so ask the processor how ownership changes or how customers and subscriptions can be moved, and plan it before close. Until it's done, revenue keeps landing in the seller's account, which needs an agreed arrangement in the deal.
6. Rotate every secret after control is proven
API keys, database passwords, webhook signing secrets, OAuth client secrets and the app's own session or token signing keys. Depending on how sessions work, rotating the signing key can sign every user out, so schedule it and tell users first. Rotate only after the buyer's access is verified, so nobody is locked out mid-change.
7. Remove access at close and agree a support window
At close, remove the seller from every account and admin role. Agree a period in which they answer questions, because undocumented behaviour will surface, without holding any access. Keep the transfer log: asset, date moved, verified by whom, secret rotated.
8. Worked example (illustrative, synthetic data)
A fictional booking app with 60 paying customers, bought from a solo founder. The seller's list: builder project, domain, email service, payment processor, analytics. Found by checking the configuration and DNS: a mapping API key on the seller's personal account, a sign-in OAuth client registered in the seller's personal cloud project, and a sending domain verified on the seller's personal email-service account. All three were recreated under the buyer before close, and the OAuth change was tested with a staff account first because it affects every sign-in. Subscriptions moved using the processor's own process. After close, 11 secrets were rotated in one evening, and the session key change was announced to users the day before.
Technical handoff checklist
Copy this structure into your review document and record your observed result for each row.
| Asset | Seller action | Buyer verification | Secrets to rotate after control is proven | Status |
|---|---|---|---|---|
| Builder project or workspace | Transfer ownership through the platform's own process | Buyer edits and redeploys from their own account | Any platform API tokens | |
| Code export or repository | Export or transfer the repository | Fresh clone builds and runs | Deploy keys | |
| Domain registration | Start the transfer or change of registrant | Buyer can edit contacts and lock settings | Registrar login and two-factor | |
| DNS | Grant access or move the zone | Buyer adds a TXT record that resolves | DNS provider API tokens | |
| Database and backups | Hand over a full backup; transfer or grant access | Backup restores to a buyer-owned environment | Database passwords and connection strings | |
| File storage | Transfer the bucket or copy the files | Buyer opens a known file | Storage access keys | |
| Email-sending domain | Hand over the sending account, or buyer re-verifies the domain | Test email sent from the buyer's account arrives | Sending API keys | |
| Payment processor | Follow the processor's ownership or migration process | New charges land in the buyer's account | API keys and webhook signing secrets | |
| OAuth app registrations | Transfer, or buyer recreates the client | Sign-in works with the buyer's client | Client secrets | |
| Other third-party APIs | List each; transfer, or buyer creates their own | App works on buyer-created keys | Every API key | |
| Analytics and error tracking | Transfer or add the buyer as owner | Buyer sees live events | Ingest keys, where they are secret | |
| Admin accounts inside the app | Create buyer admins; demote the seller | Seller's admin sign-in fails after close | Session or token signing keys |
A failure worth checking
The key that wasn't on the list. Close goes smoothly and every listed asset is transferred and verified. Three weeks later the map on every booking page stops loading: it used an API key on the seller's personal account, which the seller has since closed. Nobody listed it because nobody remembered it, and it sat in the app's configuration the whole time. Checking the configuration independently, not only the seller's list, is what catches it. The counterexample: rotating everything at the moment of close, before the buyer's own access is verified, can take the app down with nobody able to fix it. Verify control first, then rotate.
Common questions
Should the code export be tested before or after close?
Before, if the deal allows it. A failed export after close is the buyer's problem; before close it is a point to negotiate or a reason to walk away.
What happens to the users' accounts and passwords?
They stay in the app's database and move with it; don't reset them. If the sign-in provider itself has to change, treat it as a user account migration with its own plan, and tell users before anything changes.
Does this cover the legal side of the purchase?
No. Contracts, intellectual property assignment, customer terms, tax and data-protection obligations belong with the buyer's legal and financial advisers. This checklist covers technical control only.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.