Bolt.new vs Lovable: browser IDE, or a running app?

Short answer: open Lovable when you want a prompt to become a running app with accounts, data, and a deploy you can click — and you are willing to review what it generated. Open Bolt.new when you want a browser IDE: file tree, terminal, live preview, framework flexibility, and code you can edit without leaving the tab. Lovable is closer to “ship the product shell”. Bolt is closer to “ship inside an editor that happens to generate”. They meet when a founder types a sentence and expects a company.

This is for a founder, a studio shipping a client MVP, or an engineer tired of scaffolding the same login. If you already have a repo and only need a screen, you may want v0 instead — read Lovable vs v0. If the next step after the prototype is a real editor in a real repository, read Cursor vs GitHub Copilot. This piece is the split between two generators that both claim “full stack” and mean different things by it.

Both sit on Unloc under coding agents: Lovable and Bolt.new. Browse more on /tools.

Quick verdict

If you cannot say whether you need a product or an editable project, stop prompting. Write the job in one sentence. “A page a customer can sign in to” is an app. “A Next.js experiment I will tear apart in Cursor tonight” is a browser IDE job. The tools will happily do the wrong one.

What Bolt.new is for

Bolt.new is StackBlitz’s AI builder: chat with an agent, get apps and sites, run them in the browser. Under the hood sits WebContainers — a Node environment in the tab — so you get a file tree, a terminal, package installs, and a live preview without setting up a laptop toolchain. That is a real job. Studios use it for a hackathon slice, a campaign page, a prototype that must be code-visible from hour one.

Bolt’s public site emphasises model routing, large-project context management, design-system workflows, and Bolt Cloud: hosting, databases, authentication, integrations, analytics, custom domains. The point is not only “a URL appeared”. The point is “I can see and change the files”.

Framework flexibility is part of the pitch. React, Next.js, Vue, Svelte, Astro, and friends show up in comparisons and docs more often than Lovable’s opinionated React+Vite lane. If the studio’s design system or preferred meta-framework is non-negotiable, Bolt is usually the opener.

The loss is ownership theatre. A generated project in a browser tab is still code. If nobody can read a route, a query, and an env file, you do not have a product. You have a demo that will break on the first unusual request. Token usage is the other loss: Bolt’s own pricing FAQ states that most token use comes from syncing the project file system to the model — larger projects cost more per message. Debugging loops burn the month.

Treat the first generation as a draft. Click every path. Open the Code View. Push to GitHub before you invite a customer. Delete what you did not ask for while you still remember why it appeared.

What Lovable is for

Lovable takes a prompt and builds a full-stack app: the screens, the auth, a database, and a way to deploy. You iterate in chat. You can open the code. The point of the product is that a person who is not setting up a framework from scratch can get to a URL that does something. That is the same job we described in Lovable vs v0 — and it is why Lovable keeps winning founder-led MVP comparisons against tools that stop at UI.

Supabase (and Lovable Cloud as a managed path) is the practical heart. Tables, auth flows, storage, edge functions, and row-level security scaffolds from natural language are why non-technical founders finish a signup loop before lunch. The win is the stack you did not assemble. The loss is false confidence: an app with a login screen is not a security review. Missing or permissive RLS has shown up in public write-ups of AI-generated apps. Generate the draft. Do not skip the person who understands permissions.

Lovable is not a design system and it is not a substitute for a sentence about who the app is for. A prompt that says “build me a CRM” will build a picture of a CRM. A prompt that says who signs in, what they create, and what “done” looks like will build something you can test. Write that down before you type it into the chat. The chat is not the brief. The brief is the brief.

Side-by-side

Neither tool decides the offer, the permission model, or what happens when the happy path fails. You still write those down. A generated login is not a security review. A generated table is not a data model. If the product handles someone else’s information, a person who understands that information has to read the code before a stranger does.

Pricing snapshot (credits vs tokens)

Both meter generation. Both have a free way in and a paid step when you keep going. The numbers move. Read Bolt’s pricing and Lovable’s pricing page the week you buy. We are not quoting a price here that would be stale by the next invoice.

The durable difference is the unit:

• Bolt sells tokens. Bolt’s FAQ is blunt: most usage is reading and syncing project files; bigger projects use more tokens per message. Unused tokens on paid plans may roll over under current rules — check the live FAQ. Teams are typically per member with per-member allotments.
• Lovable sells credits. Plans share capacity across collaborators on some tiers. Top-ups exist. Credit burn during debugging loops is a common complaint across the category — budget for iteration, not for the first happy generation.
• A weekend prototype and a product with real users are not the same plan on either tool.
• The costly mistake is paying for both and keeping two versions of the same product, one in each generator, with two databases and two auth stories.

Organic listings on Unloc are not ranked by who paid. This piece does not use affiliate links.

Who Bolt.new is best for

Bolt is for people who want the generation and the editor in one browser tab. A technical founder. A product engineer prototyping in public. An agency pod that must respect an existing design system or a non-React stack. A hackathon that needs a shareable URL fast, with files someone can open in Cursor tonight.

It works when someone will still read the code. The prompt gets you to a preview. The review gets you to something you can leave with a client. If the team’s plan is “we will hire an engineer later to understand it”, keep the scope small enough that later is possible.

Not ideal if

• The person prompting cannot read the file tree and nobody else will. You will paste a project you cannot change on Thursday.
• You need the most guided auth-and-database path for a non-technical founder. Lovable’s loop is usually kinder.
• You wanted only a React screen inside an existing Vercel app. That is often v0 — see Lovable vs v0.
• You expected production security to appear because the preview looked finished.

Who Lovable is best for

Lovable is for a person who needs a working slice this week and does not already have the app. A founder testing whether anyone will sign up. A studio building a small internal tool. A client MVP that must take a real signup rather than a slide of a signup. It is also for an engineer who wants the boring shell generated so they can spend the day on the part that is actually specific.

It works when someone will still read the code and the RLS policies. The prompt gets you to a URL. The review gets you to something you can leave with a customer.

Not ideal if

• The app already exists and you only need a screen. You will create a second product by accident.
• You need Vue/Svelte/Astro as a first-class home. Start in Bolt or a real repo.
• Nobody can review a database query or a policy. You cannot ship other people’s data on hope.
• You need a careful, slow interface in a regulated flow. Generate the draft. Do not generate the approval.

Studio workflows

The weekend SaaS MVP

Write five lines before you prompt: who signs in, what they create, what they see afterwards, what is out of scope, and what “we will know on Monday” means. Prefer Lovable if auth and data are the risk. Generate the smallest version. Click it as a stranger. Read the schema and the policies for the one path you will show. Delete the settings page you did not ask for. Put the project in GitHub. Deploy that, and stop.

The editable prototype in a day

Open Bolt. Be specific about the framework and the components you already have. Generate. Edit in Code View. Push to GitHub. If auth is required the same day, use Bolt Cloud or connect the backend the docs support for your project type — and verify, especially if you are on Next.js versus Vite. Do not assume every backend path works for every template.

The design-system page

If the system already lives as code, Bolt’s design-system workflows and IDE surface are usually the better first open. If the system only lives in Figma, either tool will invent components; bring the tokens into the prompt and reject the second button.

The handoff to a real editor

Both tools should end in a repository the studio controls. From there, Cursor or Copilot is the next seat — not a third generator. Do not re-prompt the same app in the other builder to “make it professional”. Edit the repo.

After the prototype: security, RLS, and the honest production line

This section is the one founders skip and the one studios get paid to not skip.

Row Level Security (RLS) means database rules that decide which rows a user can read or write. AI builders will scaffold policies. They will also scaffold policies that are wrong, overly permissive, or missing on a new table you added on Tuesday. A login wall is not RLS. A “users” table is not a permission model.

Before any stranger’s data touches the app:

1. Name roles: owner, member, admin, suspended — even if you only ship two.
2. Write the denied cases: what a member must not see.
3. Open the generated policies and read them like a junior PR.
4. Try a second user. Try a logged-out request. Try a direct API call if you know how.
5. Move secrets out of the client. Edge functions and server routes exist for a reason.
6. Turn on the provider’s security advisories / linters where they exist.
7. Put the schema and env sample in the repo README so the next engineer is not archaeology.

Public reporting on AI-generated apps has repeatedly found exposed keys, missing RLS, and “it looked finished” deployments. We are not repeating unverified incident counts here. The pattern is enough: prettier demos create a false sense of security. Lovable’s strength (auth that appears early) makes this sharper. Bolt’s strength (visible code) only helps if someone reads it.

Neither Bolt nor Lovable is your SOC 2 programme. Neither is your pen test. Budget a human review before you put customer PII behind a custom domain. If that sentence feels expensive, your MVP is overscoped — cut features, not the review.

Is Bolt or Lovable better for a SaaS MVP?

Lovable is usually the safer first pick when the MVP depends on a real data model, auth, and a founder-friendly loop. Bolt is usually sharper when the MVP depends on editable code, framework choice, or a design system in the repo. Neither is the production plan by itself. The handoff plan is the MVP.

Which is more beginner friendly?

Lovable. Conversational generation and integrated backend scaffolding hide more of the toolchain. Bolt assumes you can survive a file tree when something breaks. Complete beginners still need a human when permissions appear.

Does Bolt include database and auth?

Yes, via Bolt Cloud and related product paths, and via connected backends such as Supabase where supported. Details depend on project type — check Bolt’s current docs for your framework. Do not assume feature parity with Lovable’s one-click Supabase story.

Can I export to GitHub?

Both advertise GitHub connection and code ownership. Exact sync direction, existing-repo support, and download rules differ by plan — confirm on the product docs the week you export. The repo should become the source of truth either way.

How does this compare to v0?

v0 is Vercel’s UI agent: React you drop into a codebase you already own. Lovable is closer to a running app. Bolt is closer to a browser IDE that can become an app. Read Lovable vs v0 when the brief is “component vs product”. Do not buy all three for the same screen.

Which is cheaper?

Entry paid tiers often land in a similar ballpark, but credits and tokens behave differently. Bolt cost climbs with project size because of file sync. Lovable cost climbs with iteration and debugging loops. Read both pricing pages the same week. The expensive path is the endless fix loop, not the sticker.

Can a non-technical founder ship with these?

They can ship a prototype. They should not ship other people’s data without a technical review. Lovable lowers the floor for the first URL. It does not remove accountability.

Are the apps production-ready?

No — not without review. Production means tested permissions, billing edge cases, observability, a repo you control, and a human who can explain the system without the chat history. Treat both builders as prototype engines. Promote to production on purpose.

How to decide this week

Write the artefact down. A running app a stranger can sign in to, or an editable project you will tear apart in a real editor. If it is the app with data, open Lovable, keep the scope to one path, put the result in GitHub, and read the RLS before invite. If it is the editable prototype or a non-React stack, open Bolt.new, generate against the system you have, export, and merge as a diff. If you need a screen inside an existing React app, prefer v0.

Lovable gets you to a URL that does the job. Bolt gets you to a browser IDE that can become the job. Neither one is the brief, and neither one is the security review. Use the one that matches the artefact, and do not leave the only copy of the product inside a generator chat.

Lovable and Bolt.new are on coding agents. Organic listings are not ranked by who paid. This piece does not use affiliate links. The links go to the products and to the listings already on Unloc.