Bolt and Lovable do the same job. You describe an app in plain language, it appears in your browser, and the builder hosts it at a free address. Both have a free plan, and both let you take the code. Bolt also builds mobile apps, meters you in tokens, and lets you pick Supabase for your data on the first day. Lovable builds web apps, keeps a two-way copy of your code on GitHub on every plan, and pays for building, hosting and AI features from one credit balance. Neither is a wrong choice. The right one depends on the wall you expect to hit.
Who each one is for
Bolt is made by StackBlitz and runs in the browser. It builds websites, web apps and mobile apps, the last through Expo, a toolkit for phone apps. Its docs say: “The code you create is yours to use for any legal purpose, including commercial projects.” Bolt Cloud bundles hosting, a database, sign-ups and logins, file storage and payments. Bolt says Bolt Cloud is powered by Netlify and Supabase, and you can choose Supabase, an open-source database and login service, directly when you create a project. Bolt fits the person who wants a phone app, or the data in Supabase from the start.
Lovable calls itself a platform for building web apps in natural language, “with real code.” It produces a standard React project, React being a common way of building web pages, and keeps a live two-way copy of it on GitHub, the standard place code is stored online, on every plan. Its backend, Lovable Cloud, gives you a database, logins and file storage, built on Supabase’s open-source foundation and run by Lovable, or you can connect your own Supabase project. Lovable fits the person who wants a copy of the code outside the builder from the first prompt.
What each one does well
Bolt is the more open about code coming and going. It can start from an existing GitHub repository, saves a commit for every change that does not break the project, and pulls in edits made on GitHub every thirty seconds. You can download the project as a zip at any time. Hosting is built in at a bolt.host address, with Netlify as an option.
Lovable is the more generous about staying live. Publishing is free and works even when your balance is zero. A published site stays up with no expiry and no automatic unpublishing. Cloud is included on the free plan with a monthly grant. Its ownership page says you can clone the repository, change it outside Lovable, host it anywhere, and take your data with you.
Where each one stops
Both stop at the same wall: a change the builder will not make, an error it cannot explain, or a bug that comes back while the meter runs. What differs is the shape of the meter and what you can carry out.
Bolt’s meter is tokens, the units the AI uses to read and write text. A long conversation about a large project costs more per message than a short one. The free plan has a daily cap and a monthly allowance, and neither carries over. Paid tokens carry over for a limited time, and cancelling revokes them. A custom domain needs a paid plan.
Lovable’s meter is one balance for building, hosting with Cloud, and AI features in the published app, so a live app draws from the same pot. At zero, the pages keep serving, but apps that rely on Cloud can pause, AI features stop, and building stops until credits return. The free plan’s daily and monthly grants do not roll over. GitHub sync edits one branch at a time, and Lovable cannot import a repository. A custom domain needs a paid plan here too.
How to decide
Ask three questions. Does the app need to be in an app store? Then Bolt; Lovable needs a wrapper. Where should your data live on day one? Bolt lets you choose Supabase at the start; Lovable gives you Cloud or your own Supabase, with no easy move later. How do you want to be charged? Tokens rise with the size of the conversation; one balance is simpler but shared with your live app.
| Bolt | Lovable | |
|---|---|---|
| What one prompt gives you | Screens, a database, hosting, a live bolt.host link; logins when you ask | Screens as a standard React app, a Cloud backend, a live lovable.app link |
| Where your code lives | In Bolt; zip download or GitHub sync, and Bolt can import a repository | In Lovable, with a two-way GitHub copy on every plan; export only |
| Where data and logins live | Bolt Database, or Supabase chosen at setup | Lovable Cloud, or your own Supabase |
| What kind of app | Websites, web apps and mobile apps | Web apps; app stores through a wrapper |
| How usage is metered | Tokens; free ones expire daily and monthly, paid ones carry over for a while | One credit balance for building, hosting and AI; paid credits roll over |
| When the allowance runs out | Building waits for the reset; the live site stays up | Pages keep serving; Cloud apps can pause and AI features stop |
What switching actually involves
Moving from Lovable to Bolt can start from code. Bolt imports an existing GitHub repository, and Lovable keeps one on every plan, so the screens come across as files. The backend does not: Lovable Cloud stays in Lovable, so in Bolt you start a Bolt Database or point at your own Supabase and move the data.
Moving from Bolt to Lovable is a rebuild, because Lovable only exports to GitHub and does not import. You describe the app again with the old one open as the spec, after downloading Bolt’s zip. In both directions the data and the user accounts are the slow part.
A third route fits both tools: take the GitHub copy and keep building it on your own computer with an agent such as Claude Code. That switch is covered in Lovable vs Claude Code. You can learn more, and get the full prompts and the decision tables, in our course, starting from You’ve Outgrown Lovable. The first lesson is free, no card.
In the next ten minutes, open your builder and find where your code copy is and where your data is. Then write down the one change it would not make for you. If it is about how a screen looks, either tool will do it. If it is about what happens underneath, neither builder is the answer, and the GitHub copy is your way out.