When Your Lovable or Bolt App Outgrows the Builder

An app outgrows its builder when changing it stops being cheap. That moment rarely arrives as a crash; it arrives as a Tuesday where fixing the signup form broke the dashboard, the fix for the dashboard cost forty credits, and the feature you actually wanted is still not there. Lovable and Bolt are excellent at the first version. This guide is about the handoff to Claude Code once the first version is behind you, written for founders who are not developers and are following the non-developer's path to Claude Code.

The symptoms

You do not need all of these. Two is enough.

• Edits break things you did not touch. The builder regenerates more than you asked for, and you find out from a user.
• The feature is one the chat cannot express. Background jobs, a third-party integration with real error handling, a permissions model with roles, anything where "make it work" is not a sentence.
• Credit burn is mostly regressions. You are paying to get back to where you were, not to move forward.
• A security scan found things you cannot fix from a prompt. Lovable runs a basic security scan before publishing and shows critical findings; if the fix requires understanding the Row Level Security policy rather than re-rolling the dice, you have crossed over.
• Someone technical wants a repository. A contractor, an advisor, a cofounder. They will ask for GitHub, not a share link.
• The generated code has become the product. The app is what you sell now, so who can change it safely matters more than how fast the first screen appeared.

If none of these are true, you are not there yet. Builders remain the right tool for exploration, and the vibe coding guide covers how to keep exploring without accumulating the mess that forces this handoff early.

The export that is not an export

Both builders sync to GitHub, so the repository exists before you decide anything.

Lovable. Connect GitHub from the project settings. Lovable's documentation describes the sync as two-way: changes made in Lovable sync to GitHub, and changes pushed to the active GitHub branch sync back into Lovable. Two constraints matter for the handoff. Lovable edits and syncs one branch at a time (the default branch unless you change it), and you cannot switch branches while Lovable is editing. Repositories are private by default, and if you disconnect later, the repo keeps its history and files.

Bolt. Connect GitHub from the project. Per Bolt's docs, every change that does not break the project becomes a commit, and Bolt checks GitHub about every 30 seconds for updates made outside Bolt and pulls them in. Only the project owner can connect and manage the integration; collaborators' changes sync when the owner next opens the project. Bolt does not merge branches in-app, and if Bolt and GitHub update at almost the same moment, Bolt keeps its own version and overwrites GitHub's.

That last sentence is the whole reason for the one rule below.

The backend question

The front end is the easy part; it is code in a repository. The backend is where the handoff can stall.

• Lovable with your own Supabase project. You already own the database, the auth users, and the dashboard. Claude Code can connect to it with the Supabase MCP server and nothing moves.
• Lovable Cloud. The built-in backend is built on Supabase's open-source foundation, and you can export your database and storage files from the project's advanced settings. But Lovable's docs are explicit that there is no one-click migration from Cloud to your own Supabase project: you export data, connect a Supabase project to a new Lovable project, and rebuild the schema there. Decide now whether the backend stays on Cloud (Claude Code edits the front end, Lovable keeps hosting the backend) or moves (a small project of its own).
• Bolt. The backend is whatever the project was built against. Ask Claude Code to list every external service the code calls before assuming anything.

Secrets follow the backend. Lovable stores third-party keys (Stripe, Resend, and the like) in its Secrets feature and detects keys pasted into the chat; when you move, those keys need to be re-entered wherever the code now runs, not copied into files.

The first audit with Claude Code

Open the synced repository in Claude Code and do not build anything yet. Start in Plan mode, where Claude reads files and runs read-only commands but does not edit, and ask for a tour:

Read this repository and explain, in plain language, how a user signs in, how
the app decides what they can see, where data is stored, and which external
services are called. Do not change anything.

Then audit four things, in this order.

1. Auth. Ask which routes are private and how each one checks the session. Builder output often protects the page but not the API call behind it. Have Claude list every data-fetching call and whether it runs with the user's identity.

2. Secrets. "Search the code and the build output for anything that looks like an API key, token, or service-role key. List every hit with the file." The public Supabase anon key in the browser is expected. A service-role key, a Stripe secret key, or a hardcoded password anywhere in front-end code is a launch blocker.

3. Row Level Security. Supabase's guidance is that every table in an exposed schema needs RLS enabled, because a table without it is readable and writable by any role with a grant on it. Lovable's scanners lint RLS policies for overly permissive rules, and that is a good start, but you want Claude Code to go table by table:

For every table in the migrations, tell me: is RLS enabled, what policies
exist, and in one sentence who can read and who can write. Flag any table
where the answer is "anyone".

Then test it the founder's way: sign up as a second user and try to see the first user's data.

4. Data model. The app has changed since the first prompt; the schema usually has not. Ask Claude whether the tables match what the app does today, which columns are unused, and what a feature you are about to build would need. This is where you write the one-page spec for the next phase, using the same spec-driven approach you would use for a fresh MVP.

Fix findings before features. Every fix should come with a test, because you are now the reviewer of code you did not write and cannot fully read; testing AI-generated code is the habit that makes that reviewable.

Choosing who owns the code now

The honest comparison of the two tools' strengths is in Lovable vs Claude Code. If you are earlier than that and still choosing a builder, Base44 vs Lovable covers the other common starting point, and the technical cofounder agent is a useful second opinion on the audit output before you commit to a direction. Whichever way you go, the repository is yours now. That was the point of syncing it in the first place.