Lovable

Lovable is an AI platform that builds full-stack web apps from a chat: frontend, backend, database and sign-in, backed by code you can sync to GitHub. Free gives 5 build credits a day. Pro starts at $25 a month for 100 credits, Business at $50. Custom domains need Pro. Checked 31 October 2026.

At a glance

What Lovable is

The docs open with the claim that Lovable is a "full-stack AI development platform" for building, iterating on and deploying web apps from natural language. You describe the app, Lovable generates it, you look at a live preview and ask for changes. You can publish to a live URL, or sync the code to Git and run it in your own pipeline.

It belongs to the app-builder group with Bolt and Replit Agent, the tools behind much of what people call vibe coding (see what is vibe coding). The difference from Claude Code or Cursor is the audience. Lovable is for people who want a working app and may not want to read the code, though the code is there.

The technology stack Lovable generates is not named on the documentation pages we read.

How the credits work

Lovable plans are priced by credits, not by projects or seats. Understanding credits matters more than the plan names.

Where credits come from

• Plan credits. Monthly credits added to your balance when you subscribe.
• Daily build grant. 5 credits a day, on Free (capped at 30 a month) and on paid plans too. Some regional plans cap it at 30 a month.
• Cloud, AI and connector grants. Free and paid plans get 20 Cloud credits, 4 AI credits and 1 connector credit a month, per the plans page. The FAQ states 20 Cloud and 4 for trying AI features in apps you build.
• Top-ups. Pro and Business can buy one-time or auto top-up credits.

When credits expire

Use daily grants first. They vanish at midnight, so a free user who plans work around the daily five gets more from the plan than one who leaves it idle.

Where credits go

Credits cover building (your prompts to the agent), and also running what you built: Cloud usage for the backend and AI usage for any AI features in your app. The FAQ says run and AI costs are the same on Pro and Business, but Business credits are priced higher.

Plans and prices

From the subscription plans page on 31 October 2026, in US dollars.

Pro has eleven credit tiers and Business has the same number; the table shows the first four and the top. At the same credit volume, Business costs roughly double Pro at the low end, and the gap narrows at the high end (10,000 credits is $2,250 on Pro and $4,300 on Business).

Features from the same page:

Teams: workspaces allow unlimited members on all plans, and members share the workspace's credit pool, which owners can limit per member. A student discount is available with a valid university email.

What a credit buys

The pages we read do not say how many credits a typical app costs. The safe approach is to measure: run one real task on Free, note the credits it consumed, and extrapolate before paying.

Code, Git and ownership

The docs say each project's codebase can sync to GitHub, GitLab or Bitbucket through Git sync, and that you keep full ownership of your code. After syncing, you can deploy and operate the app in your own pipeline. That is the answer to lock-in worries: your app can live outside Lovable.

Two cautions. First, syncing the frontend code is different from moving the whole backend. If you use Lovable Cloud for data and functions, check how to move them. Second, generated code still needs review.

Set up Git sync at the start of a project, not at the end. It gives you history, a backup and a route to an editor agent. A common workflow is to build the first version in Lovable and then continue in Cursor or Claude Code, covered in Cursor vibe coding and Claude Code vibe coding.

A first project, step by step

A sequence that keeps credit use low and the result reviewable:

1. Write the brief first. Who uses the app, the three things they must be able to do, and what data it stores. Five sentences are enough.
2. Prompt for the skeleton. Ask for the pages and navigation only. Check the preview.
3. Connect Git sync and make the first commit before adding features.
4. Add one feature per prompt. Sign-in, then the main data screen, then the extras. Small steps are easier to undo and cheaper to repeat.
5. Test as a stranger. Try empty forms, a wrong password and a very long input. Test on a phone-sized screen.
6. Review access rules. Check that one user cannot read another user's data. This is the most common weakness in generated apps.
7. Publish. Add a custom domain on Pro if the app is public-facing.
8. Write down what you learned, so the next project starts from your own template. A short list of prompts that worked, with the credits each one used, is the most valuable document you will make.

For deployment and security steps see deploy a vibe-coded app. If a project already works but is fragile, vibe code rescue services exist for that case.

Other ways to reach it

The welcome page lists desktop and mobile apps, plus access from Slack, Telegram and ChatGPT. There is also a Lovable MCP server, which lets you drive Lovable from your own AI tools. For MCP in general see what are MCP servers. Apps can be extended with connectors; the docs link to a connectors section and to individual integrations such as Inngest and beehiiv.

What it does well

• Speed to a working app with backend and sign-in included.
• Real Git sync for GitHub, GitLab and Bitbucket.
• Per-credit pricing across teams. No seat fees; unlimited members, with a shared pool.
• Useful free tier, with daily credits that reset.
• Several entry points, including chat apps and an MCP server.

Limits and cautions

• Credits are hard to forecast. Consumption is not published, and Business credits cost more than Pro.
• Credits expire, so annual buyers should not stockpile.
• Custom domains cost money. Free apps carry the badge and no custom domain.
• Stack and exit details. See the VERIFY items above.
• Quality is on you. Generated apps need tests and a security review. See secure a vibe-coded app.
• Data terms. We did not find a training or retention statement on the pages we read.

Lovable versus the others

For a wider list see best vibe coding tools and best vibe coding platform. Projects made with it are collected in built with Lovable.

Who should pick it

Pick Lovable if you want to turn an idea into a running web app without setting up a project, and you value Git sync as an escape hatch. It suits founders validating an idea, designers who want a working prototype, and small teams that share a credit pool. It is a weaker fit if you need strict control of the stack from day one, or if your costs must be predictable to the dollar.

Reading the credit table sensibly

The plan table has eleven Pro tiers, which looks complicated. The rule is simple: start at the lowest tier, watch real usage for a month, and move up only when credits run out before the month does. At the same credit volume, Business costs more than Pro for the same credits at low tiers, so pick Business only for the features it adds, such as single sign-on. Because monthly credits expire two months after issue, buying a large tier "just in case" wastes money. Daily grants vanish each night, so a steady habit of using the daily five beats saving them.

Habits that keep a Lovable project healthy

• Name things in your prompts. Use the same names for pages, tables and components each time, so the agent does not create duplicates.
• Ask for a summary of changes after each prompt, and read it. It is the cheapest review you will get.
• Keep a backlog outside the tool. A list of next prompts, in order, stops you spending credits on whatever occurs to you.
• Check mobile early. Look at the preview at phone width after the first screen exists, not at the end.
• Review sign-in and data rules before inviting anyone else to the app.
• Export regularly through Git sync, so a copy always exists outside the platform.

Our take

This is an editorial reading of the Lovable pricing and documentation pages, not a hands-on test.

Lovable's best design decision, on paper, is charging by credits across a workspace rather than by seat. A team of five pays for one pool, and that fits how people prototype. The cost is that credits are an abstract unit. The pricing table is detailed, but nothing in the pages we read converts a credit into a feature, so measure on the free daily grant before you pay.

The other thing we would do is set up Git sync on day one. The docs make code ownership a headline, and the Git route makes it real. Treat Lovable as the fast first draft and your repository as the product. That keeps the option to move to an editor agent when the app outgrows chat prompts, and it keeps a copy outside any vendor's pricing changes.

Checklist

• Start on Free and measure what one real task costs in credits
• Connect Git sync before building anything you want to keep
• Use the daily credits before they expire
• Buy Pro only for a custom domain, the badge removal or volume
• Check how backend data moves if you leave
• Review generated code for sign-in and input handling
• Re-check pricing on lovable.dev before subscribing