How to Hand Off an AI-Built App to a Client

AI tools have changed what a freelancer or small agency can deliver. An app that used to be a three-month build is now a few weeks. That's a genuine opportunity — and it's creating a new, common failure: the build goes brilliantly, and the handoff is a mess.

The client gets a link and a repository they can't read. The domain is registered in your account. The database is on your credit card. Six months later something breaks, and you're either doing unpaid support or the client discovers they can't get their own app out of your accounts.

A good handoff is mostly about ownership and expectations. Here's how to do both.

Decide the model before you start

There are really three ways a client app can be run after launch. Agree which one in the contract, not at the end:

Model	The client gets	You get
Full handoff	Everything in their name; they or their next developer run it	A clean exit
Handoff + retainer	Everything in their name; you maintain it for a monthly fee	Recurring revenue
Managed service	A working app; you own and run the infrastructure	Recurring revenue, and all the responsibility

The trap is drifting into the third model by accident — running production for a client with no agreement, no fee, and no end date. Pick deliberately.

Principle: the client owns the accounts

Whatever model you choose, the client should own every account the business depends on. You get access; they hold the keys.

That means, in the client's name and billed to the client:

The domain, at a registrar, with two-factor authentication on.
The GitHub repository (or organisation), with you added as a collaborator.
The hosting account.
The database, or the platform that provides it.
Payment provider (Stripe or similar), connected to their bank.
Email sending service and DNS records.
Any AI or API provider the app calls, with a spending limit.
Analytics and error monitoring.

The easiest way to get this right is to create these accounts with the client at the start of the project, on a call, with them entering their own payment details. Transferring things at the end is always harder than starting them in the right place.

What to hand over

1. Access, verified

Don't just send credentials. Watch the client (or their new developer) log into each account themselves and confirm they're an owner or admin. Then remove any of your personal credentials from their systems, and use your own collaborator access from then on.

2. A one-page runbook

Not documentation for developers — a page the client can actually use. Keep it short:

What the app is made of, in plain language: "The website runs on X. The data is in a database on Y. Emails are sent by Z."
Where each account lives and who has access.
What costs money, roughly how much per month, and which card pays.
What to do if it's down: who to contact, and where to check status.
What not to touch: the settings that would break things.

3. Technical notes for the next developer

The client may not keep you forever. A README in the repository should cover:

How to run the app locally.
Every environment variable, what it's for, and where its value lives (never the values themselves).
How deployment works.
How the database schema is changed (migrations) and how backups are restored.
Anything unusual or fragile.

If the project was built with an AI agent, commit a CLAUDE.md too. It lets the next person — or the next AI session — pick up the project's conventions immediately. See How to Write a CLAUDE.md.

4. Proof that backups work

Show that the database has automated backups, and do one test restore before the handoff. A client who's told "it's backed up" and later finds it wasn't will not be a client for long. (How: How to Back Up a Postgres Database.)

The pre-handoff checklist

Every account in the client's name, with the client confirmed as owner
Custom domain connected, HTTPS working, auto-renew on
Production and development databases separated
Backups automated and a restore tested
No secrets in the code; all in the host's environment settings
Security basics checked — especially database access rules (checklist)
Payments tested end to end in live mode
Error alerts going to someone who will read them
Runbook and README delivered
Support terms written down

Set support expectations in writing

The most expensive sentence in freelancing is "just let me know if anything comes up."

Instead, write down:

A warranty period — for example, 30 days of fixes for defects in what you delivered, at no charge.
What counts as a defect versus a new feature.
After the warranty, either a monthly retainer with a defined scope and response time, or an hourly rate for ad hoc work.
What's excluded: third-party outages, changes the client makes, new features.

Clients generally respect clear terms. What damages relationships is ambiguity followed by an invoice.

If you choose to keep running it

A maintenance retainer can be a good business, especially across several clients. If you go that way:

Standardise your stack across clients so maintenance knowledge compounds.
Use a platform that handles the infrastructure — backups, certificates, updates — so your retainer pays for improvements, not babysitting servers.
Still keep the domain and data in the client's name. You're providing a service, not holding their business hostage.

The short version

Create accounts in the client's name from day one. Hand over access they've verified, a one-page runbook, and a README. Test the backups. Write the support terms down. Do that, and the handoff becomes the reason clients come back — instead of the reason they don't.

EasySpawn is built for this workflow: each client project in its own workspace, with managed Postgres, daily backups, automatic SSL, and the client's own domain connected — plus flat team pricing with no per-seat fees. See how it works for AI-built apps or see pricing.