A freelancer's checklist before handing off an AI-built app to a client

You built the app fast with Lovable or Cursor. It works, the client is happy, and now you want to hand it over and get paid. The problem is the handoff itself. Six weeks later the client emails you because the site is down, the database is full, or nobody can find the login for the payment account. That’s on you, unless you did the handoff right.

Here’s the checklist I’d run before I called any AI-built project “delivered.”

Credentials and account ownership

The single biggest handoff failure is accounts that live under your name. When you disappear, so does access.

Move every account to the client’s email. Hosting, database, domain registrar, Stripe, email sending (Resend, Postmark), analytics. If it can’t be transferred, make sure the client is the billing owner and you’re just a collaborator.
The client owns the domain. Not you, not “the agency account.” The domain should sit in a registrar account the client controls, with the client’s payment card on file. A lapsed domain kills the whole app, and auto-renew on your card is a liability for both of you.
Payment accounts are the client’s legal entity. Stripe, PayPal, whatever takes money. This has to be the client’s business, tax ID, and bank account. Never route a client’s revenue through your own Stripe. That’s not a favor, it’s a mess waiting to happen.
Write down every login in one place. A password manager vault shared with the client beats a Google Doc full of plaintext passwords. Include the recovery email and 2FA method for each account. If a login uses your phone for 2FA, fix that before you leave.

Backups that actually exist

Most AI-built apps ship with no real backup. The platform might keep snapshots for 7 to 14 days, but that’s not something the client controls, and it won’t survive an account closure or a bad migration.

Confirm a backup exists and where it lives. “The platform does it” is not an answer you can hand a client. Know the exact retention window and who can trigger a restore.
Do one test restore before handoff. Restore the database to a scratch copy and confirm the data comes back. A backup you’ve never restored is a guess. This is the step everyone skips and the one that saves the client’s business.
Document the restore steps. Write the exact commands or clicks to recover data, in plain language, so a stranger could follow them at 2am. If recovery depends on a tool only you know, that’s a gap.

If the app holds anything that matters (customers, orders, bookings), point the client at real backup with point-in-time recovery, not just platform snapshots. See how to back up a Lovable or Supabase app for the difference.

Environment variables and secrets

AI code generators love to scatter API keys around. Before handoff, make sure none of them are exposed and all of them are documented.

Check for keys in the code. Search the repo for anything that looks like a live key (sk_live, AKIA, long random strings). AI tools sometimes hardcode secrets instead of using environment variables. If you find one, rotate it and move it to an env var. A 5-minute exposed-key check covers the common spots.
List every environment variable the app needs to run. Name, what it’s for, and where the value comes from. The client should be able to rebuild the environment from this list alone.
Rotate any secret you’ve ever seen. If a key passed through your machine, your Slack, or your email, treat it as compromised and generate a fresh one under the client’s account.

Documentation a non-developer can use

The client probably can’t read the code. They need to know how to run the business, not how the router works.

A one-page “how to run this” doc. How to log in as admin, where the data lives, how to add or refund a customer, who to call when it breaks. Keep it to a page.
How to make a safe change. If the client will keep vibe-coding features, tell them how to branch, test, and roll back so one bad prompt doesn’t take the site down.
A dependency and cost list. Every paid service, its monthly cost, and the renewal date. Clients get blindsided by a $200 charge they didn’t know was coming. List it up front.
Your support terms in writing. Are you on the hook for 30 days? Billing hourly after that? Gone completely? Say so. A clear boundary protects the relationship.

The 10-minute final check

Before you send the “it’s yours” email, run through this:

Client can log in to hosting, database, domain, and payments with their own credentials.
Domain auto-renews on the client’s card.
A backup exists, and you’ve restored it once.
No live secrets in the code; all keys documented and owned by the client.
The “how to run this” doc exists and a non-developer could follow it.
Every paid service is listed with its cost and renewal date.
Your support scope is written down.

If any of these fail, you’re not done. You’re just hoping the client never has a bad day.

Or, we do it for you

If the app matters and you don’t want to own the ops burden after handoff, we run a free audit that covers exactly this list: backups, secrets, ownership, and the “can this survive a bad day” question. Point your client at a Stackbastion audit and hand off with a clean report instead of crossed fingers.

FAQ

What if the client wants to keep using the AI builder after handoff?

That’s fine, and common. Just make sure they know how to make a change safely: work on a copy, test it, and know how to roll back. The risk isn’t the AI tool, it’s an unreviewed change going straight to the live app with no way back. Give them a simple branching and backup routine before you leave.

Do I really need to test a restore, or is confirming the backup enough?

Test the restore. A backup that’s never been restored fails more often than people expect: wrong permissions, a corrupt file, a missing table. It takes 20 minutes to restore to a scratch database and confirm the data is really there. That 20 minutes is the difference between a backup and a rumor.

Who should own the domain and payment accounts, me or the client?

The client, always. The domain sits in a registrar account they control with their card on file. Payments run through their legal entity and bank account. If you hold these, you become a single point of failure, and routing a client’s revenue through your Stripe creates tax and liability problems you don’t want.

The client is non-technical. How much documentation is enough?

One page they can actually use, plus a list of accounts and costs. Skip the architecture diagrams. Cover how to log in as admin, where the data lives, how to handle a customer, what each paid service costs, and who to call when something breaks. If a non-developer can run the business from your doc, it’s enough.