One of the most useful questions I have seen a maker ask, almost word for word: when a builder says you own your code or can export, what does that mean in practice? Do you get the full source or just the frontend while the backend stays on their platform? If you export, will it actually run elsewhere, or is it so tangled in platform-specific services that the export is technically real but practically useless? What happens to a deployed app if you stop paying, and is the database yours too, or only the app code?
That is the right set of questions, and the fact that makers have to ask tells you the marketing pages are not answering them. The same anxiety shows up everywhere: people burning hundreds of dollars testing eleven builders just to learn which ones let you leave, and threads titled "stop paying to code on platforms you do not control." Here are the three questions that matter, then a builder-by-builder read.
"Own your code" is three questions, not one
Before you trust any export button, separate these:
- Source completeness. Do you get the whole application, or just the UI layer while the logic and backend stay on the platform?
- Runnability elsewhere. Does the exported code boot on your own machine and your own host, or is it wired to proprietary services that do not exist outside the builder?
- Data and deployment custody. If you stop paying tomorrow, do you keep the database and a deployable artifact, or does the running app and its data go dark with the subscription?
A builder can pass one of these and fail the others. "We export your code" can be perfectly true while the export is practically useless because it fails questions two or three. Hold each builder to all three.
Lovable: real export, backend lives in Supabase
Lovable scores well. On paid plans it offers two-way GitHub sync: your edits in Lovable land in your GitHub repo, and pushes back into the branch sync into Lovable. On the free plan you can still download the project as a ZIP. The export includes your React, Tailwind, routing, full folder structure, and Supabase configuration, and per Lovable's terms you own that code for commercial use and can deploy it anywhere, including Vercel, Netlify, Railway, or your own server.
The honest catch is question three. The backend, your data and auth, lives in Supabase. "Moving off Lovable" really means keeping or migrating that Supabase project. The good news is Supabase is itself portable Postgres, so this is a manageable dependency rather than a trap. The day-one move: connect GitHub immediately so the source is never only inside Lovable.
Bolt: ZIP download, but mind the WebContainer layer
Bolt (bolt.new, built by StackBlitz on top of their open-source repo) lets you export. Click the project title, choose Export, then Download, and you get a ZIP of the project. You can push to GitHub as well. So question one, source completeness, is satisfied for the app code.
Two wrinkles on runnability. Bolt runs your generated code in the browser using StackBlitz WebContainers, and as of April 2026 StackBlitz changed how Bolt stores project code, so the older "Open in StackBlitz" path is no longer available for projects on the new format. Separately, the WebContainer technology that powers the in-browser dev environment requires a commercial license for production use. That does not affect your downloaded code, which is a normal app you host yourself, but it is worth knowing that the in-builder runtime is not something you take with you. Export, run it locally, host it on your own infrastructure.
v0: you own the components, but it is a UI generator
v0 by Vercel generates Next.js, React, TypeScript, shadcn/ui frontend code that you can copy out or push to GitHub, and you own it. The catch is not ownership, it is scope. v0 is a UI generation tool, not a full-stack app builder. It does not produce backend logic, database schemas, API routes, authentication, or infrastructure config. Ask for a full app and you get the frontend plus a note to handle the rest yourself.
One warning from the Vercel community: some users found that the ZIP or connected GitHub repo contained only a README without the actual source. Open your export and confirm it has real code before you assume you have it. With v0 the portability question is less "can I leave" and more "I only ever had the front half, so the backend is mine to build and own regardless."
Replit: many exit doors, hosted deployment and DB
Replit gives you the most exit routes. You can download your project as a ZIP, download single files, push to GitHub from the version-control panel, and there is now an official bulk export that pulls all your repls including environment variables and configuration so you can move off cleanly. Source completeness and runnability are both in good shape.
The custody question is where to be careful. The convenient parts, the always-on deployment and Replit's hosted database, are Replit infrastructure. The code is yours and runs elsewhere, but if you lean on Replit's built-in database and hosting, plan the equivalent on your destination host before you cut over. Export early, run it on your machine once, and you will know exactly what is portable and what you have to recreate.
Bubble: no source export, plan for it knowingly
Bubble is the clear outlier. It does not export source code, full stop. You can get your data out through its API or CSV, but the application logic itself cannot leave the platform. If you outgrow Bubble or want to hand the project to developers, the migration path is rebuilding the app from scratch on another stack. This is real, permanent vendor lock-in, and it is the single most expensive surprise in this space because the rebuild cost lands on top of everything you already spent.
This is not automatically a dealbreaker. Bubble is genuinely capable, and plenty of apps live their whole life on it happily. But you should choose it knowing the exit does not exist, and you should be doubly aware of the platform's other binding constraint: its Workload Unit pricing, which can spike unpredictably. Lock-in plus metered cost is a combination to enter with eyes open.
How to stay portable from day one
Portability is mostly decided early, by habit, not by a heroic migration later. Four rules:
- Connect GitHub on day one. The moment the source lives in a repo you control, the builder becomes an editor, not a vault. This alone defuses most lock-in fear.
- Keep data in a database you can take with you. Your own Postgres, a Supabase project, or a hosted API behind your own key. Avoid platform-only data primitives for anything load-bearing. When fast-moving state outgrows a spreadsheet-style store, reach for a portable key-value store rather than a proprietary one.
- Do an export-and-run drill while the app is small. Download the code, run it on your own machine, deploy it to a throwaway host. If it boots without the builder, you own it. If it does not, you have found your lock-in before it cost you anything.
- Decide what you are deliberately renting. It is fine to rent hosting, auth, or a managed database for convenience. Lock-in only hurts when it is a surprise. Write down which dependencies are rentals you could replace and which are traps you cannot.
The honest framing
Lock-in is not a yes-or-no property of a tool, it is a gradient, and where you land is partly your choice. Lovable, Bolt, v0, and Replit all let you walk out with real code; the differences are in who keeps the backend and the live deployment. Bubble does not let you walk out at all, which is a legitimate trade for some teams and a quiet disaster for others. Either way the move is the same: own the repo from day one, own the data, and prove your exit works before you need it. That is what separates owning your code from owning a screenshot of it.
It is also why the smartest makers stop treating one platform as the whole stack. Keep the builder for what it is great at, then graduate the parts that outgrew it onto services you control, and know when "we run it ourselves" is a real requirement versus procurement theater. Portability is a posture, not a single decision.