Lovable vs Bolt, judged on what happens after the build

The comparison table, extended past the build

Every published comparison on this query has the same shape: a verdict, a feature grid, a same-prompt bake-off, and a "choose Bolt if / choose Lovable if" close — all organised around the build. This table is organised around the eight questions that arrive after it, in the order they arrive. The third column is ours; read it with that in mind.

Read the second-to-last row before the others. It disqualifies us for most of what people build with Lovable and Bolt, and it is not going to move: Clize serves pre-built files, with form submissions and checkout bolted on the side. If your thing has accounts and a database, the two browser builders are answering your question and we are not.

The rest of the table is the part nobody prints — not because the other reviews got it wrong, but because "which one builds faster" and "where does this end up living" are different questions and only the first has been written about.

Where each one is genuinely stronger

On the build itself the published testing is good and there is no reason to redo it. The most careful of the ranking pages, nocode.mba's 2026 head-to-head, gave both tools the same prompt — a Trello-style task app with drag and drop — then the same follow-ups. Its findings:

• Bolt was faster off the line: a working first version in about 30 seconds against about 60 for Lovable, which spends that extra half-minute writing a plan first.
• Bolt's lead compounds across an editing session, because it applies diffs — rewriting only what changed rather than regenerating larger sections.
• Lovable produced the cleaner structure as the feature list grew (boards, due dates, comments), asking for clarification instead of guessing.
• Lovable's advantages are onboarding-shaped: plan before code, first-class Supabase integration, GitHub sync, and mock data in what it generates.

A clean split: Bolt suits someone who reads diffs and prototypes fast across whatever framework the job needs; Lovable suits someone who has not been a developer for ten years and wants the data layer decided for them. Both are real strengths, and neither has anything to do with the rest of this page. A tool can win the build convincingly and still hand you something that is not, in any sense a customer would recognise, launched.

Why the preview subdomain is the actual problem

Of the ten results on this query, exactly one goes near deployment: getautonoma, at position eight, with headings for speed to first deploy, deployment options, and code export and ownership. It still stops inside the platform — the deploy it measures ends on a hosted preview address, and "who hosts this after you export it" is left open.

That gap matters more than a thirty-second generation difference. A preview address proves the code renders. It does not give you:

• A name you would print. your-app-9f3c.preview-host.app does not go on a business card, in a signature, or in an ad.
• An address people can reply to. The moment the site says "get in touch", something has to receive the mail — and a builder that ships hosting almost never ships a mailbox.
• Control of the certificate and the redirect behaviour. www versus apex, and whether a missing URL returns a real 404 or your homepage with a 200 — small things that decide whether the site is indexable at all.
• Portability. A preview URL is a tenancy. When the plan lapses, the link in someone's bookmark dies with it.

This rarely shows up in comparisons because it is boring and it lands on you rather than on the tool. The build is a demo you can film; the domain, the DNS, the certificate and the mailbox are four dashboards. But if the reason you opened Bolt or Lovable was "I need a site up by Friday", they are most of Friday.

Code export, and what leaving actually costs

Both tools answer the lock-in question the same way, and honestly as far as it goes: you can get the code out. Lovable syncs to GitHub, Bolt exports the project. The source is not hostage.

What the export does not include is the running site. It hands you a repository and leaves you holding a checklist: a build pipeline to reproduce somewhere, a host account, a deploy that is now your job to trigger, DNS records to re-point with the propagation wait attached, a certificate to issue and keep renewing, redirect and 404 behaviour reconstructed from whatever the platform did implicitly — and, if the old site could be contacted at all, an inbox to rebuild.

None of that is hard. All of it is unbilled hours, landing in a week when you had a different reason for changing tools. That is why our own eight-way round-up of Lovable alternatives treats the wiring, not the code, as the real price of doing it yourself. The way to shrink that bill is not a nicer platform — it is to have the deploy, the domain and the mailbox be commands you already own, so that moving is just running them against a different folder.

The third path: a coding agent and one deploy command

Ours, so weigh it accordingly. The shape differs enough from the two above to be worth describing rather than scoring. You do not get an editor: the thing that writes the site is the coding agent you already pay for — Claude Code, the Codex CLI, Pi, OpenClaw — working in your own repo. What Clize adds is the layer that agent cannot reach on its own: a design method so the output does not look generated, and the deploy, domain, certificate and mailbox as commands the agent runs itself.

$ npm i -g @clize/clize
$ clize login
$ clize install            # writes the skill into every agent on this machine

Claiming a name comes before writing any code, because the deploy needs a target and names are first come, first served:

$ clize claim mystudio --email
✓ mystudio.clize.app is yours; the site and support@mystudio.clize.app are in place.

Without --email the handle is site-only; inbound is off by default to conserve the shared zone's DNS records. The agent then takes the design method and previews locally with clize build site start and clize serve ./site. The step the other two paths spread across four dashboards is one line:

$ clize deploy ./site --domain mystudio.clize.app
Live at https://mystudio.clize.app (14 files: 14 KV + 0 R2; uploaded 14, skipped 0; TLS automatic)

To land on a name you own instead, the agent can find and register one — and the money gate is what makes it safe to leave that command in an agent's hands:

$ clize domain search mystudio
$ clize domain buy mystudio.com         # quote only. Nothing is registered.
$ clize domain buy mystudio.com --confirm
$ clize deploy ./site --domain mystudio.com
$ clize email setup mystudio.com        # support@mystudio.com: MX, SPF, DKIM, DMARC

Every command that spends money prints a quote and stops; --confirm is the action, and outbound mail works the same way — the agent drafts, you confirm. The certificate takes roughly thirty seconds. The full walkthrough in Claude Code has the same chain with the design steps expanded.

When neither of them — and not us either

Clize hosts static sites. HTML, CSS, JavaScript and assets, served from storage, plus form and waitlist submissions forwarded to an endpoint you name and self-service checkout with real payments. It does not run a backend, a database, or a logged-in application, and there is no server-side rendering — a framework project is fine as long as its output is static files.

So if the brief has accounts, a dashboard, or data users write and read back, stop reading this column — Lovable with Supabase, or Bolt with whatever you wire, is the right answer, and one of the platforms in the wider alternatives comparison is built for exactly that.

If you will not open a terminal, this is not for you either. There is no visual editor. Both browser builders are strictly better for someone who wants to stay in a browser tab.

The free tier is a real tier, not a trial: three handles, five mailboxes, twenty deploys a day, 500 MB per site. A domain costs what the registrar charges, quoted before it is bought, and nothing about the hosting expires on a clock.

One question that settles it

Not three questions — one, asked in the right order. Does the thing you are building need to remember a user?

If yes — logins, saved records, anything read back later — you need a backend, and the choice is between Lovable (fastest to a working data layer, easiest if you are not a developer) and Bolt (faster iterations, more control, any framework). Pick on the build criteria above and ignore the rest of this page.

If no — marketing, a launch page, a portfolio, documentation, an event — the build is the easy half and the question is where it lives afterwards. Then ask: do you already work in a coding agent? If you do, the third path is shorter and ends on a domain you own. If you do not, use whichever browser builder you like better and budget an afternoon for the domain, the certificate and the mailbox.

That is the whole decision. The thirty-second generation gap is real, and for a five-page marketing site you will iterate on for a week it is the least important number here.

For the wider field, eight options compared by what you are actually building covers v0, Replit, Dyad, WeWeb and Webflow alongside them; the HTML file host is the shortest version if you already have a file in hand; and Sites by Clize is the category page for the third path.

$ npm i -g @clize/clize && clize login
$ clize install
$ clize claim mystudio --email
$ clize deploy ./site --domain mystudio.clize.app