Lovable, Bolt and v0 vs Claude Code: App Builders or a Coding Agent

Lovable, Bolt and v0 are app builders: you describe an app in a browser chat, they write the code, run it in a preview, give it a database and sign-in, and publish it to a live address. Claude Code is a coding agent: it works in a repository you already have, on your machine or in the cloud, reading the code, running your commands and editing files under rules you set. The builders own the whole path from idea to hosting, which is why they are quick to start. Claude Code owns none of it, which is why it fits a codebase that has to last. Many projects use both, one after the other, and the handover between them is where most of the trouble is.

What each app builder is

• Lovable: a full-stack builder for web apps. Its built-in backend, Lovable Cloud, provides the database, authentication, storage, edge functions and hosting. New projects have used TanStack Start since 13 May 2026; older ones are React with Vite, and Lovable offers an upgrade.
• Bolt: a builder for websites, web apps and mobile apps (through Expo) that runs entirely in the browser, using StackBlitz’s WebContainers to run Node.js there. Bolt Cloud adds a database, hosting and domains. You pick a Standard or a Max agent depending on how hard the task is, and Bolt chooses the model behind it.
• v0: Vercel’s builder, working in Next.js, React, TypeScript, Tailwind CSS and shadcn/ui. Projects run in a sandbox and deploy to Vercel. Its sandboxes also come with coding agents pre-installed, including Claude Code, which you can start from the v0 terminal.

All three let you look at and edit the code they write, and none asks you to install anything. Lovable and v0 can also connect remote MCP servers to the chat, so the builder can read context from tools such as Linear or Notion while it works.

What Claude Code is

Anthropic’s Claude Code overview↗ (opens in a new tab) calls it an agentic coding tool that reads your codebase, edits files, runs commands and integrates with your development tools, in the terminal, an IDE, a desktop app or the browser. It does not choose your stack, host your app or provide a database; it works with whatever the repository already uses. Its instructions come from a CLAUDE.md file you commit, its reach is set by permission rules and hooks, and its changes arrive as commits and pull requests you review.

Where the code lives

This is the question that decides how easy it is to leave. All three builders sync to GitHub, but they do it differently.

• Lovable syncs both ways with one GitHub repository. Lovable’s GitHub documentation↗ (opens in a new tab) says changes pushed to the active branch flow back into Lovable, but it syncs one branch at a time; commits on another branch do not appear. Individual files can be downloaded on any plan and the whole codebase as a zip on paid plans.
• Bolt pushes to GitHub and, according to Bolt’s GitHub guide↗ (opens in a new tab), checks GitHub every 30 seconds for changes made elsewhere. If Bolt and GitHub change at almost the same moment, Bolt keeps its own version and overwrites GitHub’s. Branches can be created in Bolt, but merging happens on GitHub.
• v0 creates a private repository and then works like a colleague: v0’s GitHub guide↗ (opens in a new tab) describes a working branch per chat, a preview deployment for each, and a pull request that Publish merges. Once connected, the repository is the source of truth. You can also import an existing repository or a zip.
• Claude Code has no copy of its own. The code is in your repository from the start, and nothing is hosted anywhere you did not choose.

Who each suits

• A founder or product manager testing an idea with real users this week: a builder. Hosting, sign-in and a database come with it. How to do this without losing the plan is in vibe coding for product managers.
• A designer turning a mock-up into a working front end: v0 or Lovable, both of which take Figma files.
• A team with an existing codebase, tests and a deployment pipeline: Claude Code, because it works inside what is already there.
• Anything with years ahead of it, several contributors or regulated data: a repository you control and a coding agent, even if a builder wrote the first version.
• Mobile: Bolt builds Expo apps from the browser; Claude Code works on any mobile codebase you already have.

Handing over from a builder to a coding agent

The common path is to prototype in a builder and move to a repository once the app matters. Done carelessly, the two tools overwrite each other. A handover that holds:

1. Connect the builder to GitHub and confirm the repository has everything: migrations, edge or server functions, environment variable names (not values) and the build command.
2. Decide who edits which branch. Lovable edits one branch, and Bolt wins a simultaneous change. Either stop editing in the builder, or give the builder its own branch and let Claude Code work on others through pull requests.
3. Clone it and run it locally before asking an agent to change anything. If it does not build on your machine, the agent’s first hour goes on that.
4. Write a short CLAUDE.md: the stack, the exact commands to install, run, test and build, and what never to touch, such as the generated database types or the auth configuration. CLAUDE.md examples shows the shape.
5. Move secrets out of the builder’s settings into your own environment or hosting provider, and rotate any key that was ever pasted into a chat.
6. Turn the builder chat’s unfinished ideas into written tasks with acceptance criteria. Spec-driven development is the fuller version of this step.

The same care applies in the other direction. If Claude Code changes a Lovable project’s active branch, Lovable will pick up the change; if it changes a Bolt project while someone is prompting Bolt, one of the two changes may be lost.

Security basics for generated apps

An app that works in the preview can still let any visitor read every row in the database. Each builder has checks, and each is clear about their scope. Lovable’s security overview↗ (opens in a new tab) describes a quick scan before publishing and a deeper scan on demand, and says plainly that these tools cannot guarantee complete security. Bolt runs a database security check on all plans and a fuller audit on paid ones. v0 warns when code exposes values through NEXT_PUBLIC_ variables, which Next.js sends to the browser.

• Access rules on every table. On a Supabase-style backend that means row-level security policies, tested by signing in as two different users.
• No secret in the browser. Anything in a public or VITE_ or NEXT_PUBLIC_ variable is readable by anyone.
• Server-side checks on every write, not just a hidden button.
• A dependency audit, and a review of any package the builder added that you do not recognise.
• A person reads the auth and payment code before real users arrive, whichever tool wrote it.

Claude Code does not replace these checks. It can run them, and hooks can stop it editing files you have ruled out, but what it writes still needs reviewing the same way.

Keep the backlog outside the chat

Both kinds of tool lose the plan the same way: it lives in a chat history. Ideas, known bugs and what was decided are scattered through hundreds of prompts, and the next tool, or the next person, cannot see them. A task board fixes that. With fenbs connected over MCP, Claude Code reads the task it was given, files a bug for what it notices, and comments when it stops, and every change is recorded under the assistant’s name. The builder phase fits the same board: write down each feature before you prompt for it, and the handover list above is half written already.