Leaving the AI app builder: what it takes to move an app off Lovable, Bolt or Replit

The app started as a weekend on an AI app builder. You typed what you wanted, the builder wrote it, and a few weeks later real customers sign in every day. Now there is a reason to move: the monthly bill has grown with the app, a customer's security review asks where the data lives, a developer you hired wants to work in their own tools, or you simply want the business to stop depending on one vendor's pricing page.

The good news is that the main builders let you take the code. The less obvious news is that the code is the easy part. An app is code plus a database, user accounts, stored files, secrets, background functions and a hosting setup, and each builder handles those differently. This article goes through what you actually own on Lovable, Bolt and Replit, what breaks on the way out, what it costs in days for a small app, and the few habits that keep the exit open from the first week.

What an app on a builder is made of

Before comparing builders, list the pieces. Every one of them has to land somewhere when you leave.

The rest of this article is mostly about the bottom six rows.

Lovable: the code syncs, the backend exports with limits

Lovable writes a standard web front end and, for most new apps, uses its own built-in backend, Lovable Cloud. The code side is the friendliest of the three. Lovable connects a project to a GitHub repository that it creates for you, private by default, and keeps it in sync both ways: "Lovable only edits and syncs one branch at a time", usually main, and changes you push to that branch come back into the editor (Lovable, GitHub integration). If you disconnect, "your repository stays on GitHub". You can also download the code directly on paid plans. Two limits worth knowing: you cannot import an existing repository into Lovable, only export, and reconnecting a project creates a new repository rather than reusing the old one.

The backend is where the work is. Lovable says its built-in backend "utilizes Supabase's open-source foundation", and also says plainly that "there is no one-click migration from the built-in backend (Cloud) to your own Supabase project" (Lovable, Cloud). What you get is an export. According to Lovable's advanced settings page, "the export contains your full database, both structure and data", including user accounts with their password hashes, so users restored into a Supabase project of your own can keep their passwords (Lovable, Advanced settings). The limits: databases up to 15 GB, an export file of at most 5 GB, one export every 24 hours, and only while the backend is running. Storage files, edge function code and secrets are not in the export and move separately.

That password-hash detail matters more than anything else on this list. It is the difference between a quiet move and an email to every customer asking them to reset their password.

One warning: removing Lovable Cloud from a project is permanent and deletes the instance. Take the export and download the stored files first, and keep both somewhere that is not the builder.

Bolt: download the project, export the data table by table

Bolt makes the code easy too. Click the project title, then Export and Download, and you get a zipped folder of the project; GitHub is the other route (Bolt, Manage your projects). Projects are usually ordinary Vite or Next.js apps that run with Node.js on any machine. Secrets are not in the download, so the app will not start until you recreate its .env file.

The database is less clear. Bolt's built-in database lets you select rows in a table and export them as CSV or JSON, but its documentation does not describe a whole-database export, and it says "there's currently no supported way to migrate an existing Bolt database to Supabase", while another part of the same page mentions claiming the database into your own Supabase account (Bolt, Database). We could not reconcile those two statements from the documentation alone, so ask Bolt support which applies to your project before you plan around either. Bolt's pages also say nothing about exporting the users who signed up, so assume they have to be invited again, or moved with help from support.

If your Bolt project was set up from the start with your own Supabase account (Pro and Teams plans can choose that), most of this goes away: the database, users and files are already in an account you control.

Replit: Postgres you can dump, sign-in that belongs to Replit

Replit gives you a normal Postgres database reached through a DATABASE_URL secret, and its own documentation shows the export: open the Shell and run pg_dump -Fc "database_url" --no-owner --no-privileges -f backup.dump (Replit, Shared database migration). That is the cleanest database exit of the three. Code comes out as a zip from the file tree or through GitHub; Railway's guide for moving from Replit adds that the .replit and replit.nix files should be removed because other hosts do not read them, and that every secret has to be copied by hand (Railway, Migrate from Replit).

Sign-in is the catch. With Replit Auth, someone who signs in to your app is "creating or using an existing Replit account", on a Replit-branded login page (Replit, Replit Auth). Your customers' identities are Replit's, not yours. The page documents it working on replit.dev, replit.app and custom domains served by Replit, and points apps that use it to a migration to Clerk, a separate sign-in service whose accounts are "not tied to Replit". If you want to leave Replit someday, do that migration while you are still on Replit, with its documented flow and testing steps, rather than during the move.

What breaks on the way out

Even with every export in hand, a few things fail the first time the app runs somewhere else. In rough order of how often they bite:

1. Secrets and keys. None of the three copies them out. List every key in the secrets panel before you start, and rotate the ones that were ever pasted into a chat with the builder.
2. Sign-in redirect addresses. Google sign-in, magic links and password-reset emails all point at the builder's domain. Each provider's settings need the new address, or sign-in fails with an unhelpful error.
3. Server functions. Edge functions are code you can copy, but their schedules, environment variables and secrets are configuration that lives in the builder. Rebuild them one by one and call each once by hand.
4. Database rules. Supabase-based apps rely on row-level security policies to stop one customer reading another's rows. Check that they came across in the export and are switched on in the new project; an app that works but has lost its policies is worse than one that fails. Our five checks for a live Lovable app include the commands to test this from the outside.
5. Stored files. Uploaded pictures and documents sit in storage buckets, and the database holds links to them. Move the files first, then rewrite the links, then check a few old records open.
6. Emails. Welcome, verification and reset emails were sent by the builder's backend from its templates and its sending domain. Set up your own sender and copy the templates over.
7. Things only the builder did. Preview links, scheduled jobs, analytics, the custom domain's certificate. Write each one down as you notice it.

How many days, for a small app

For a small app (a few thousand users, a dozen tables, some uploaded files, two or three server functions), this is our estimate for one developer who knows the target stack. It is a planning figure, not a measured average.

The spread comes mostly from two rows: users and server functions. An app whose users can be restored with their passwords and which has almost no server functions sits at the low end. An app on a sign-in service you cannot export from, with nightly jobs and payment webhooks, sits at the high end or past it. Plan a switch-over evening with the old app set to read-only, so no orders or sign-ups land in the old database after the export.

Before you start, it is worth checking whether the app you are moving is in good enough shape to be worth moving as it is. If not, the move is a good moment to fix it; our six checks for an AI-built prototype are a short list to go through.

Keeping the exit open from the first week

Most of the cost above is decided in the first few days on a builder, long before anyone thinks of leaving. Five habits keep it small:

- Connect GitHub on day one. The repository then holds every change with its history, and a developer can read it without an account on the builder.
- Own the backend account where you can. If the builder lets you connect your own Supabase project instead of its built-in backend, the database, users and files are in an account you pay for and control from the start.
- Choose a sign-in you can take with you. Email and password or Google sign-in stored in your own database moves; accounts that belong to the builder do not.
- Keep a list of keys and settings outside the builder. A password manager entry per app with every secret, redirect address and webhook is half of the inventory step done.
- Take an export every month and open it. A backup you have never restored is a guess. Restore it into a scratch database once, count the rows, and you know the exit works.

None of this means you should leave. For many small businesses the builder is still the cheapest way to run the app, and the bill is the price of not running servers. The point is that staying should be a choice you make with the exit tested, not a default you find out about when the reason to leave arrives.

Sources

Lovable, GitHub integration (two-way sync, one branch, export only, private repositories, code download on paid plans); Lovable, Cloud (built on Supabase, no one-click migration to your own Supabase); Lovable, Advanced settings (what the Cloud export contains, password hashes, size and frequency limits); Bolt, Manage your projects (project download); Bolt, Database (table export as CSV or JSON, Supabase migration statements); Replit, Replit Auth (sign-in with Replit accounts, migration to Clerk); Replit, Shared database migration (DATABASE_URL and the pg_dump command); Railway, Migrate from Replit (Replit files to remove, secrets copied by hand). Pages read on 15 October 2026; the builders change their products often, so check the current pages for yours. The day estimates are our own planning figures, not measurements.