Hand Over an AI-Built App to a Client Without Regrets
The app works, the client is happy, and then you realise the domain, the database and the API keys are all in your name. A handover checklist for freelancers and small agencies.
To hand over an AI-built app to a client, transfer six things in a deliberate order: the domain, the hosting account, the database and its data, the third-party keys, the code repository and the documentation. Then confirm the app still runs under the client's own accounts before you step away. Most handover problems come from one of those six still sitting in your name.
Why handover goes wrong with AI-built apps
An app built quickly with an AI tool often grows out of a single account. You signed up for hosting, a database, an email provider and a payment tool on your own login so you could move fast. Everything works. Nothing is separated.
When the project ends, the client sees a working product and assumes they own it. If your invoice, your email address or your card sits behind any of those services, they do not control their own app. That becomes a problem the day you are unavailable, or the relationship ends badly.
Agree what the client owns in your contract first. If you have not, contract clauses for an AI-built app covers ownership and delivery terms, and who owns AI-generated code explains why the question is not as obvious as it sounds. This article assumes the answer is "the client owns the deliverable" and covers the mechanics.
The six things to transfer
1. The domain
Do this first, because it is the one with a built-in waiting period. ICANN's transfer policy allows a registrar to deny a transfer requested within 60 days of a domain's creation, and requires a 60-day inter-registrar lock after a change of registrant unless the holder opted out beforehand. (That is the 2016 text. ICANN's page notes a newer version was published on 21 February 2024, so check the current one before you plan dates.) The policy also says registrars must give the holder the AuthInfo code, the unique code used to authorise a transfer.
The practical lesson: if you registered the domain for the client, check the registrar's rules before you change the registrant details. Changing the owner name and then trying to move registrars immediately can trigger the lock. If the domain is new, a transfer in the first 60 days may be refused. For the technical side of pointing a domain at an app, see moving an AI-built app to a custom domain.
2. The hosting account
Ask the client to create their own account with the hosting provider, then move the project into it, or use the provider's project transfer feature if it has one. Add yourself as a collaborator afterwards if you will keep maintaining the app.
3. The database and its data
Export a backup, restore it into an account owned by the client, and verify that row counts match. Record where backups run and who receives failure alerts.
4. Third-party keys and services
List every service the app touches: email, payments, analytics, file storage, AI model providers. For each one:
Who owns the account?
Where is the key stored?
What happens if the key is revoked?
Rotate keys at handover. Create fresh keys under the client's accounts, update the app's environment variables, and revoke yours. Keys should never be emailed in plain text.
5. The code repository
Transfer the repository or give the client an organisation-owned copy. Include the commit history so the next developer can see why decisions were made. Confirm nothing secret is stored in the code.
6. The documentation
Write a short document covering how to deploy, where environment variables live, how to restore a backup, and which services cost money each month. For the writing itself, a handover document prompt turns your notes into a readable file.
The order that avoids pain
Agree ownership in the contract.
Start the domain transfer first, because of the waiting periods.
Client creates hosting, database and service accounts.
Migrate data and move the app into those accounts.
Rotate every key and revoke your own.
Transfer the repository and send the documentation.
Run a final test with the client logged in under their own accounts.
The final test
Do not close the project until the client, not you, can do these four things: log in to every account listed, deploy a trivial change, restore a backup into a scratch environment, and read a month's costs from the billing pages. If any of them needs your login, the handover is not finished.
After handover
Decide in writing what happens next. Either the engagement ends, or you move to a maintenance arrangement with defined scope and price, as laid out in structuring a retainer for ongoing AI app maintenance. A vague "call me if something breaks" turns into unpaid work. The wider business context sits in AI monetization strategies.
Frequently asked questions
What should I give a client when delivering an app?
Access to the domain, hosting, database and service accounts in their name, the code repository, fresh keys, and a short document on how to run and restore the app.
How long does a domain transfer take?
It depends on the registrar, and rules can apply. ICANN's policy allows a registrar to deny transfers within 60 days of creation and requires a 60-day lock after a change of registrant unless the holder opted out. Check the registrar's own page before you start.
Should I keep access to the app after handover?
Only with the client's written agreement and ideally as a named collaborator with limited access, tied to a maintenance arrangement.
Do I need to rotate API keys when I hand over a project?
Yes. Keys created under your accounts should be replaced with keys under the client's accounts, and yours should be revoked.
How did this land?
About the author
Growth & SEO Lead
Manuele covers distribution: SEO, content strategy, and how AI-built products find their first thousand users. He tests everything he recommends.
