Moving a Project From Lovable to Claude Code Is a Smaller Lift Than You'd Think

Briefly Brilliant, an LSAT prep app I built in Lovable, hit the point where I needed full control over the code and the deployment. Lovable is great for getting something working fast. It's not built for the level of control I needed next. So I moved it to Claude Code, and I want to walk through exactly what that took, because it was a smaller lift than I expected.

Lovable generates standard React, Vite, and Tailwind under the hood. Nothing exotic to untangle, no proprietary format to reverse-engineer. That mattered more than I realized going in.

The only real setup was environment variables, and this is the part worth being careful with. Lovable connects to Supabase by default. The Supabase project itself stays completely untouched during a migration like this. You're not moving data or rebuilding a database. You're just pointing your local .env file at the same project URL and the same API key Lovable was already using. Same backend, different front door.

Then came the deployment decision. Vercel, not Railway. That distinction matters and it's easy to get backwards if you haven't hosted both kinds of apps before: Vercel is built for a React app that talks out to a service like Supabase. Railway is built for backend servers running persistent processes. Briefly Brilliant is the former. Railway would have worked, technically, but it would have been the wrong tool for what the app actually needed.

Here's the honest summary of what changes and what doesn't. What changes: your dev environment, and your deploy pipeline. What stays exactly the same: the database, every row of data in it, and every line of code that was already written. You're not rebuilding the app. You're changing where you work on it and how it gets shipped.

The migration checklist

The migration is real work, but it's bounded work. Knowing exactly what changes and what doesn't going in is what keeps it from turning into a bigger project than it needs to be.