# What should I check before handing an AI-built app to a client?

**Answer:** Make sure the client ends up owning every account the app runs on, that every secret you or your tools saw is rotated, and that the production settings outside the repo are written down. On a Vercel + Supabase app that means transferring the Vercel project and the Supabase project, rotating keys, listing env vars per environment, and checking the auth, email, webhook and backup settings in each dashboard.

## Why this matters

A handoff moves responsibility, not only code. Settings that live in dashboards do not travel with the repository, a Vercel project transfer leaves env vars defined in vercel.json behind, and a Supabase project transfer has its own prerequisites. Keys saved outside the codebase during the build stay valid until someone rotates them.

## Check before the handoff

- Transfer the Vercel project to the client's team. You must be an owner of the team you transfer from and a member of the target team. The transfer lists the domains and env vars it moves; env vars defined in the env or build.env keys of vercel.json have to be set again, integrations linked to the project (a Supabase integration, for example) have to be added again after the transfer, and usage and logs do not move.
- Transfer the Supabase project to the client's organization. You must own the source organization and be a member of the target one, and the project cannot have an active GitHub integration connection or log drains. Moving to a Free plan organization can cost features.
- Give the client owner access before you remove your own. Supabase suggests more than one owner on an organization so one lost account does not lock everyone out.
- Rotate the keys after the transfer: Supabase secret keys and Stripe API keys. Stripe's go-live checklist asks you to rotate keys in case they were saved outside the codebase during development, and Supabase documents how to rotate a leaked secret key.
- Write down every env var name per Vercel environment (Production, Preview, Development) and where its value comes from. Changes apply only to new deployments, so redeploy after changing one.
- In Stripe, confirm live mode on its own: live webhook endpoints registered, each handler verifying signatures with that endpoint's signing secret, and no test mode objects such as products, plans or coupons in production code, since test objects are not usable in live mode.
- In Supabase Auth, set the Site URL to the client's production domain and keep the redirect URL list to exact production paths.
- Move auth email to an SMTP account the client controls. Without custom SMTP, Supabase only sends auth email to members of the project's team.
- Put the backup plan in writing. Free plan projects have no downloadable backups; Pro, Team and Enterprise projects keep daily backups for 7, 14 and up to 30 days; files in Storage are not in database backups.
- Check that production matches the repo: supabase migration list for applied migrations, and the Security Advisor for public tables without RLS.
- Hand over the steps no file records: dashboard settings, DNS records, webhook endpoints, and who to contact when something breaks.
- Turn on multi-factor authentication for the accounts the client now owns, including GitHub if they sign in to Supabase with it.

## Optional repo check

For AI-built Vercel + Supabase apps, `npx -y viberaven@1.5.3 check` can give the client a list of repo launch gaps to start from: public tables that no migration puts under row level security, policies whose condition is a bare `true`, a Supabase service role key in client code, env vars the code reads that `.env.example` does not list (it cannot see Vercel settings), secret files that `.gitignore` does not cover, and Stripe webhook handlers that skip the signature check over the raw body. It is advice, not a gate, and a repository check, not a live database test: the accounts, keys, dashboards and backups above are outside its view. It exits with code 1 when it finds a blocker and writes a `.viberaven` folder that it does not add to `.gitignore`.

## FAQ

### Do env vars move when I transfer a Vercel project?

The transfer shows the env vars it moves with the project. Env vars defined in the env or build.env keys of vercel.json are not transferred; Vercel says to migrate them to the project settings or set them again on the target team.

### Do I need to rotate keys if the client keeps the same accounts?

Rotate any key that was saved outside the client's control during the build. Stripe recommends rotating keys before going live for that reason, and Supabase's API key guide covers rotating a leaked secret key.

## Sources

- Vercel, Transferring a project: https://vercel.com/docs/projects/transferring-projects
- Vercel, Environment variables: https://vercel.com/docs/environment-variables
- Supabase, Project Transfers: https://supabase.com/docs/guides/platform/project-transfer
- Supabase, Production Checklist: https://supabase.com/docs/guides/deployment/going-into-prod
- Supabase, API keys: https://supabase.com/docs/guides/api/api-keys
- Supabase, Redirect URLs: https://supabase.com/docs/guides/auth/redirect-urls
- Supabase, Custom SMTP: https://supabase.com/docs/guides/auth/auth-smtp
- Supabase, Database Backups: https://supabase.com/docs/guides/platform/backups
- Stripe, Go-live checklist: https://docs.stripe.com/get-started/checklist/go-live
- Stripe, Receive events in your webhook endpoint: https://docs.stripe.com/webhooks

HTML page: https://viberaven.dev/ai-built-app-client-handoff-checklist