How to hand over an AI-built app to developers

To hand over an AI-built app to developers, first move every account the app depends on into your company's name. Then give the developers the code with its full history, a list of every service and secret the app uses, and a written account of what the app must do and must never do. Finish by asking them to release a change and roll it back without your help. Getting the code across is the easy part; Lovable, for example, syncs a project to GitHub in both directions. What gets lost is the knowledge of how the app is meant to behave, and the access nobody wrote down.

This guide is for founders who built an app with Lovable, Bolt, v0, Replit or another AI tool and now want engineers to take it further. Platform details are from each vendor's documentation as of 30 September 2026, listed under Sources.

What does handing over an AI-built app to developers involve?

Three things move: ownership, knowledge and responsibility. Ownership is the code, the data and the accounts. Knowledge is what the app is for, the rules it enforces and the decisions behind its quirks. Responsibility is who releases changes, who is alerted when it breaks and who can restore the data. A code handover is complete only when all three have moved.

AI-built apps make the knowledge part harder than usual. Nobody wrote the code line by line, so nobody can explain it from memory, and the prompts that produced it are rarely a reliable record of what it does now. The handover has to rebuild that knowledge from the running app.

What should you do before the developers start?

Put everything in your company's name first, while you still control it. A developer given access to an account you do not own can be locked out with you.

• Code: move the repository to a GitHub organisation your company owns. GitHub keeps the issues, pull requests and history when a repository is transferred, and redirects the old address to the new one.
• Lovable sync: according to Lovable's documentation, sync continues after a transfer if your workspace has a GitHub connection for the new owner; otherwise the project disconnects.
• Database: if the app runs on your own Supabase project, transfer it to a Supabase organisation you own. You must be an owner of the source organisation and at least a member of the target one, and a transfer cannot move a project between regions.
• Everything else: domain, email sending, payments, analytics, error monitoring and app-store accounts should all be registered to the company, with you as owner and the developers as named members.

If the app still runs on Lovable Cloud rather than your own Supabase project, decide whether to move it before the handover or as the developers' first job. Our guide to migrating off Lovable Cloud covers what the export includes and what it leaves behind.

What should the handover pack include?

Write it once and keep it in the repository, so the next handover is easier. It does not need to be long; it needs to be true.

1. 01What the app is forWho uses it, the three or four journeys that matter most, and what it costs you when each one breaks.
2. 02The rules it must keepWho may see and change what, what must never happen twice, and anything required by law or by a customer contract.
3. 03A map of the systemEnvironments, hosting, database, storage, scheduled jobs, email, payments, AI providers and every other outside service.
4. 04An inventory of secretsThe name and purpose of every key and where it is stored. Never the values: send those through the platform's own secrets settings, never by email or chat.
5. 05How it is released todayWhere the live app is built from, how a change reaches users, and whether there is any way back.
6. 06What you already know is wrongKnown bugs, workarounds, features that were half built, and anything a customer has complained about.

A developer who gets this pack can start by checking the app instead of guessing at it. One who does not will spend the first weeks reconstructing it.

How do you hand over a Lovable app to developers?

Through GitHub. Lovable's documentation describes a two-way sync: changes made in Lovable are pushed to the connected repository, and changes pushed to the active branch are pulled back into Lovable. A few details decide whether that helps or hurts:

• Lovable edits and syncs one branch at a time, the repository's default branch unless you choose another in the project's GitHub settings.
• When GitHub rejects a push, Lovable writes to a branch named lovable-sync instead, for someone to review and merge by hand.
• Export only goes one way: Lovable can create a repository from a project, but cannot import an existing repository.
• If you disconnect, the repository stays on GitHub with its history; syncing simply stops.

Agree early who edits the synced branch. If you keep prompting in Lovable while developers push to the same branch, you will overwrite each other. The usual arrangement is that developers work on their own branches and merge through reviewed pull requests, while you keep designing in Lovable. That split is how we work too, and our guide to taking a Lovable app to production explains what changes underneath.

What will developers check first?

Whether the app can be verified at all. Good developers start by measuring: does it build, does it type-check, do the tests pass, what does the linter report, and who can read which table. Only then do they know which changes are safe. That first pass is often a code audit.

The results can be surprising. When our engineers took over Looph, a customer-feedback product shaped in Lovable, type checking had never run, lint reported 19,849 problems, so a real one was invisible, and two tests failed on code nobody had touched. There were 1,152 tests at handover; there are now 10,387, passing in CI, and Looph is live in production. The Looph case study describes the gates that made the difference.

Bell's prototype, an AI email assistant with 143 database tables, is another example: its browser queried the database directly, and the review of its row-level security covered about 12 of those tables. None of that is visible from the screens, which is why developers look underneath before they add anything.

How do you know the handover is complete?

When the new team can do the everyday and the emergency jobs without asking you or the previous builder. Test it with a short list:

1. Release a small change to production and roll it back.
2. Run the app locally and on a staging environment that is not production.
3. Restore the database to a copy from a backup and check the data.
4. Rotate one secret without downtime.
5. Receive an alert when something fails, and know who acts on it.

Anything they have to ask for was missing from the handover. Add it to the pack, then run the list again.

What goes wrong when AI-built apps change hands?

• Accounts in a freelancer's or builder's personal name, discovered when that person stops replying.
• Secrets pasted into chat or email, then never rotated.
• Nobody knowing which environment the live app is actually built from.
• Prompting in Lovable and developer commits landing on the same branch and undoing each other.
• A full rebuild started without a written account of what the app must do, so the rebuild quietly drops rules the prototype enforced.

Plans start at $2,999 a month paid annually, or $3,999 month to month; see pricing. To see how far your app is from production first, take the free production-readiness check.

Sources

Each platform fact above comes from one of these pages, checked on 30 September 2026.

• Lovable documentation: GitHub integration (docs.lovable.dev/integrations/github).
• GitHub documentation: Transferring a repository (docs.github.com).
• Supabase documentation: Project transfers (supabase.com/docs/guides/platform/project-transfer).
• Stripe documentation: API keys, on not sharing keys over email or chat (docs.stripe.com/keys).
• Case-study facts: our Looph and Bell case studies, as published on this site.