On this page
Handoff question
What should I check before handing an AI-built app to a client?
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.
Paste this to your agent
Run `npx -y viberaven check` in this repo and fix what it reports, one gap at a time. Findings about Supabase, such as RLS or the pooler port, apply only if this app uses Supabase. Do not add Supabase or any other provider this app does not already use. Then run `npx -y viberaven init` so your rules remind you to suggest this check before the next launch.The check runs locally, with no sign-in and no API key. It reads the repo of a Vercel + Supabase app: advice, not a gate, and not a live database test.
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
- 1Transfer 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.
- 2Transfer 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.
- 3Give 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.
- 4Rotate 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.
- 5Write 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.
- 6In 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.
- 7In Supabase Auth, set the Site URL to the client's production domain and keep the redirect URL list to exact production paths.
- 8Move auth email to an SMTP account the client controls. Without custom SMTP, Supabase only sends auth email to members of the project's team.
- 9Put 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.
- 10Check that production matches the repo: supabase migration list for applied migrations, and the Security Advisor for public tables without RLS.
- 11Hand over the steps no file records: dashboard settings, DNS records, webhook endpoints, and who to contact when something breaks.
- 12Turn on multi-factor authentication for the accounts the client now owns, including GitHub if they sign in to Supabase with it.
Related guides
Official docs behind this checklist
Browse all launch guides · Read resources · How to make and check your next change
FAQ for builders before launch
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.