Why I left Lovable

What it is and why it matters

Lovable is convenient. The reason I left is something else: inside a platform like that, the code lives with them, the deploy goes through them, and they set the prices. I prefer a project that sits in a folder of mine.

In my opinion, a year ago that convenience made sense, because the other tools were hard. Today with Claude Code I ask for the same things I'd ask Lovable for, writing as if in a chat, and in the end the project is mine: I take it wherever I want.

It's my choice, not a rule. If you're happy where you are, stay: this guide is still useful, because having your own copy of everything never hurts.

The thing is, a project isn't just the code: there's the data, the users' accounts, the uploaded files, the keys, the domain. Each piece leaves through a different door, and if you forget one, you find out when a user can't get in anymore.

One rule before anything else: don't delete anything until the new one works.

1. The code on a GitHub of your own

On Lovable: Project settings → Git → GitHub. You connect your account and have it create the repository: Lovable creates it as private and keeps it synced both ways, what you change in Lovable goes to GitHub and vice versa.

On Replit: Tools → Git. If the project doesn't have a repository yet, press “Initialize Git Repository.” Then you connect GitHub (the first time, Replit asks you to authorize it), make a commit and push all the files.

Then you clone the repository to your computer, from the “Code” button on the repo's page on GitHub. From here on, it's a folder of yours.

2. The database: structure and data

The code carries the database's structure, not the data. On Lovable the structure lives in the migrations, SQL files usually in the supabase/migrations folder. The data, meaning the actual rows, you export separately.

Without the data you have an empty app.

On Lovable Cloud the database export is in the advanced Cloud settings: More → Cloud → Overview → Advanced settings → Export data. The link arrives by email: it's a Postgres backup archive, with structure and data, and you restore it with pg_restore. Uploaded files and keys are left out: you move them by hand, as I explain further down.

On Replit there are two databases. You use the development one while you build. The published app uses the production one, and that's where your users' data lives: that's the one to export.

Open the Database tool and pick the production one. In the My Data tab you can export the data to a file. The Settings tab has the connection string: according to Replit's documentation, any PostgreSQL-compatible client can connect to the production database, so pg_dump can too. Treat it like a password.

You import it into a Postgres or Supabase of your own, new and empty.

3. Environment variables and keys

Secret variables don't come out with the code or with the database export. And on Lovable secrets can't be read back, only replaced: you get the value from the service that gave it to you.

On Replit you find them in Tools → Secrets, with the values visible. If the app is published, also check the production secrets in the Publishing settings: they can be different.

List them all: database, APIs, payments, email. Put them in the .env on your computer and in the new hosting's settings, never in the code.

When the new app works, regenerate all of them and revoke the old ones: they went through another platform, and you no longer know where they ended up.

4. Users, files, domain

The users

Login accounts don't travel with the tables: if you only move the data, the users stay behind.

The full Lovable Cloud export does include them, with the passwords encrypted. If you restore it into a Supabase project, users keep their password; the sessions don't come over, so everyone will log in again.

On Replit, in Tools → Users & Auth, Users tab, you see who has signed up. With Replit Auth, users sign in with a Replit account. Their rows in the database travel with the data, the way in doesn't: decide on the new login first and on how to let existing users back in.

If you're coming from a different route and the passwords can't be carried over, prepare a “reset your password” email to send on the day of the switch.

The uploaded files

Photos, documents, avatars: they're not in the database and they're not in the code. On Lovable Cloud you find them in More → Cloud → Storage. Download them and upload them again to the new storage, into buckets (the storage's “folders”) with the same names.

On Replit they're in App Storage: Tools → App Storage, pick the bucket from the menu at the top left, and in the Objects view you download each file with the icon next to it.

Then count the files before and after.

The domain

Write down where the domain is registered and copy its current DNS records before you change them. On Replit the linked domain is in Publishing, Domains tab. If you bought it inside the platform, check how to transfer it before you close anything.

5. Open the folder with Claude Code

Open the terminal in the project folder and start Claude Code (cd into the folder, then claude). It reads the files on its own. I give it these requests, in this order.

Read the whole project and explain to me how it's built: framework, database, login, external services. Give me the list of the environment variables it needs.

This is the map. In Replit projects the app usually finds the database through the DATABASE_URL variable: on the new setup it will have to point to yours.

Create a .env.example file with all the variables, without real values, and add .env to the .gitignore.

The .env.example has only the names. The real values live in the .env, on your computer, and the .gitignore tells git never to upload it.

Get it running locally. If something depends on the old platform, tell me what and suggest how to replace it.

This is where the hidden things come out: a login that goes through the platform, an address written in the code. How much Claude Code asks before acting depends on the permission mode, which you change with Shift+Tab. When it asks, read what it's about to do before you say yes.

Import the database dump into a local database and check that the pages show the real data.

You need Postgres on your computer: if it's missing, ask Claude Code to help you install it. Then open the app: if you see your users and your content, the data is there.

6. Publish where you're in control

Prepare the deploy to [Vercel / your server]: tell me the steps, the variables to set and what to change in the DNS. Don't touch anything until I say ok.

The last sentence matters: I want to read the plan first. You can also use plan mode (Shift+Tab, or /plan in front of the prompt): Claude writes a plan and doesn't edit the files until you approve it.

Before you move the domain, test everything on the address the new hosting gives you: login with an old account, an uploaded file, payments in test mode. Then, only when the new version works, in this order:

1. You move the domain, and add the new address to the redirect URLs your login allows.
2. You regenerate the keys and revoke the old ones.
3. You switch off the old version.

Common mistakes

• Exporting the development database from Replit. The published app's data lives in the production one: export that.
• Writing the real values in the .env.example. Only the names go there; the values live in the .env, which git ignores.
• Forgetting how users get in. Decide on the new login first, and on how existing users will get back in.
• Copying the old keys over to the new one and calling it done. Regenerate them and revoke the old ones.

Checklist

• Code on a GitHub of your own, private, cloned to the computer
• Structure and data exported from the production database
• List of variables and .env.example without real values
• Users, files and DNS records saved
• App running locally with the real data
• Login, files and payments tested on the new hosting
• Domain moved, keys regenerated, old version switched off last

Frequently asked questions