Guides · Ownership
Guides · Ownership
On paper, you own the code Lovable, Bolt or v0 generated for you: their terms say what you create is yours. In practice, code ownership means being able to clone the code, run it without the platform, and control the database and keys it depends on. Most exported prototypes fail that second test, and this guide shows you how to check yours.
This is the ownership chapter of our complete guide to taking a Lovable prototype to production. Prospects ask us one version of this question more than any other: how can I be sure the product stays mine?
Lovable syncs your project to a GitHub repo under your account, and its own documentation confirms the code is yours to keep, commercially and without ongoing fees. That part is real: you can clone the repo, open it in an editor and keep every line if you cancel your subscription tomorrow.
The repo is the beginning of ownership, not the end of it. What lands in GitHub is your frontend and whatever backend logic the builder wired up, still shaped around the platform's assumptions and still pointed at infrastructure you may not control.
Bolt.new exports the whole project as a zip: standard React code you can run locally, backend logic included, per Bolt's help center. v0 works in the other direction, generating components you paste into a codebase you already own, so there is nothing to export in the first place.
One catch with Bolt: the export leaves out everything in its Secrets panel, so your API keys and service URLs don't travel with the code. And hosted builders such as Base44 each draw the line differently. Before you build anything serious on one, check whether export hands you the backend or only the screens.
An export gives you source files. It does not give you the database and the user accounts in it, the keys to your payment and AI providers, or the pipeline that turns code into a running product. Those stay wherever the builder put them, usually under accounts created during a tutorial and never touched since.
The exported code is still worth having. When Fity brought us their WhatsApp coaching bot, one monolithic file with features failing constantly, we rebuilt it using their code as the base rather than starting over. But an export inherits its flaws too, including the security holes we keep finding in AI-generated apps, so owning the file is not the same as owning something you'd ship.
When a developer or agency writes code for you, ownership is whatever the contract says, so settle it before work starts. Two things belong in writing: the repo lives under your own account, and full ownership of the code and IP transfers to you at a defined point.
That's how we run every migration. The code sits in a GitHub repo under the client's account from the first day, and ownership of code and IP transfers on final payment. No platform to be locked into afterwards, nothing held hostage.
Ask these five questions, and treat any "no" as rent. One, can you clone the code to your machine and run it? Two, does the export include the backend, or only the screens? Three, is the database under an account you control? Four, could you deploy the app somewhere other than the builder this week? Five, if you stopped paying the platform tomorrow, would anything keep running?
Five yeses mean you own a product. Anything less means the builder still owns a piece of it, and what moving from rented to owned costs, tier by tier, is on the pricing page. The other questions founders ask before handing us a prototype are answered on the FAQ page.
Founder and main developer at Zyntari. Building apps and AI solutions since 2024; before that, 12 years in sales and client-portfolio management and co-founder of two companies. More about the team · LinkedIn