away from lovableYou are here when
You hire a developer, bring in a co-founder, or hand the app to a client or a buyer.
What usually goes wrong at this stage
- Accounts in the wrong name. The app runs on GitHub, Lovable, the host, the database, the domain, email sending and every paid service it calls. Whoever signed up first owns each one, and whose card it charges is often a surprise. Owners handing an app to a client feel this first: “I sold a website to a client … but I am pretty confused on how to actually transfer it to them” (r/lovable, September 2026).
- Moving the GitHub repository without checking Lovable. A transfer to another account keeps the sync running only when the Lovable workspace also has a GitHub connection for the new owner; without one, Lovable disconnects the project, and connecting again creates a new repository (Lovable docs).
- The domain. It is often in a personal account at a registrar, and whoever controls it controls where your visitors go.
- Shared passwords and old keys. When someone leaves, every key they could see has to be replaced.
What it costs: an afternoon to list every service and who owns it, then one account move at a time.
What this stage gets you
Every service with a named owner and a named payer, everyone on their own login, and changes that reach the main copy of the code through pull requests someone who reads code has reviewed. Lovable’s docs describe keeping Lovable on its synced branch while developers work on feature branches that are merged through review (Lovable docs).
When to move on
This is the last stage. If the app keeps real users, the check from stage 3 stays with every release.
Short answers for this stage
The full stage, step by step with the agent prompts, is in the paid guide that comes with the kit.