What does Lovable cost?

Lovable works with a single credit balance instead of separate subscriptions per component. That makes the pricing question harder to answer than "$X per month": what you pay depends on how much you build, how heavily your Cloud project runs, and how many AI features you use. Below we explain the mechanism, the order of magnitude of the costs, and how to keep control of your usage.

For up-to-date rates, always check lovable.dev/pricing — prices and credit amounts can change, and we don't want to hand you an outdated figure. Just want to get started: start for free with Lovable.

One credit balance for everything

Lovable used to have separate dollar balances for Cloud (database, auth, storage) and AI (text, chat, images). Since the August 2026 update, that has been merged into a single credit balance covering three things:

Usage	What it is
Build usage	Messages and edits you send to Lovable to build or adjust your app
Cloud usage	Hosting and backend usage of your published app (database, auth, storage, server functions, built on Supabase)
AI usage	Text, chat, image and embedding features in your published app (Gemini and OpenAI models, no need for your own API keys)

The underlying cost of running projects hasn't changed with this switch — only the way you see and pay for it has.

Daily build credits: the free baseline

Besides your monthly credits (on paid plans), everyone gets daily build credits:

• 5 daily build credits per day, refreshed every day.
• On the Free plan this is capped at 30 per calendar month.
• Resets happen at 00:00 UTC; unused daily credits don't roll over to the next day.
• On paid plans, daily credits come on top of your monthly credit budget, with no monthly cap.

That means on Free you can experiment every day, but during a busy build week you'll quickly hit the monthly maximum.

Free, Pro, Business and Enterprise at a glance

	Free	Pro	Business	Enterprise
Monthly subscription credits	None	From 100/month	From 100/month	Volume-based
Indicative price	Free	From ~$25/month (about €0.30 per credit)	From ~$50/month (about €0.60 per credit)	Custom
Daily build credits	5/day, max 30/month	5/day, no monthly cap	5/day, no monthly cap	Custom
Cloud grant	20 credits/month	20 credits/month	20 credits/month	Custom
AI grant	4 credits/month	4 credits/month	4 credits/month	Custom
Rollover credits	No	Yes	Yes	Yes
Top-ups / auto top-up	No	Yes	Yes	Yes
Code download	No	Yes	Yes	Yes
Per-member limits	No	Yes	Yes, more extensive	Yes, governance-level
Extra	—	—	More advanced controls/governance	Volume, scale, governance

Free is fine for finding out whether Lovable fits how you like to work, but without code download and with a hard monthly cap, it's no basis for a production project. Pro is the starting point for most independent builders and small teams; Business mainly adds governance and team control, but it is clearly more expensive per credit (roughly twice the price of Pro for the same number of credits); Enterprise is driven by scale and compliance.

Reported order of magnitude in the market: subscriptions starting around $25–$50 per month plus usage-based top-ups (Value Add VC, July 2026). This is a reported figure, not a price list we've verified ourselves — check lovable.dev/pricing for the exact, current rates per plan.

Top-ups, auto top-up and rollovers

On paid plans you can buy credits on demand (top-ups) or set up auto top-up, which automatically tops up once your balance drops below a threshold. That prevents a project from stalling mid build session or, worse, mid production, because of an empty balance. Unused monthly credits roll over on Pro and above; daily build credits never do.

Where credits actually go in practice

Credits rarely disappear evenly. In practice we see three big consumers:

1. Large, unfocused change requests. One prompt that "rewrites the whole flow" costs considerably more than a series of small, targeted changes — and more often produces a result you need to correct again.
2. Debugging without clear error information. A prompt like "it doesn't work" forces the model to guess. Attaching console and network logs saves iterations.
3. Repeated iterations on the same problem. If the third attempt doesn't work, the fourth is unlikely to without changing something else — a good moment to go back to planning instead of prompting again.

10 tips to save credits

#	Tip
1	Work in small, well-defined steps instead of one big change per prompt
2	Use plan mode before you start building, especially for new features
3	Include console and network logs with a bug report
4	Describe the desired end result concretely, not just the problem
5	Test after every step instead of stacking three changes before checking
6	Use git sync (GitHub/GitLab) so you can revert to a working version
7	Put new experiments in a separate branch or copy, not in the main project
8	Avoid repeated "try this again" prompts; change the approach, not just the attempt
9	Keep an eye on your Cloud instance scale as you grow; an instance that's too small causes timeouts and extra debugging rounds
10	Export and document your data model early, so you're not prompting blind about a structure you no longer have clear in your own head

The total cost of ownership

The Lovable subscription is one line on the bill, not the whole bill. Also budget for:

• Domain: connecting a custom domain to your published app costs separate money at your domain registrar, outside of Lovable.
• External APIs: if you connect your own services outside Lovable AI (payments, email outside Lovable Email, external data sources), those costs run through that provider.
• Ongoing development: an MVP that keeps growing requires ongoing prompt work and therefore ongoing credit usage; it's not a one-off cost.
• What an agency engagement adds: guidance on architecture choices, code review, testing, authorization/RLS settings, and an actual delivery with documentation. With "vibe coding" these are real concerns (July 2026 reporting on security and maintainability of AI-generated code), and they don't disappear just by having more credits.

Your projects and code are, incidentally, simply yours as a user, regardless of plan (see the FAQ on lovable.dev/pricing) — but downloading code is only possible from Pro upwards.

What we recommend

• Start on Free with Lovable to test whether the way of working suits you.
• Move to Pro once you're seriously building a project you want to be able to download and keep developing.
• Budget not just for the subscription, but also for the domain, any external services, and the ongoing time that further development keeps costing.
• If you're unsure whether an AI-built app is the right foundation for something that needs to keep running, have a technical check done before going live.

Frequently asked questions

Is Lovable free to use? Yes, the Free plan gives daily build credits up to a monthly maximum of 30, without code download and without rollover.

What does an average project cost? That depends heavily on scope, iterations and Cloud usage; there's no fixed amount. See lovable.dev/pricing for the plans, and start small to gauge your usage.

Can I run out of credits without my app going offline? With auto top-up you prevent an empty balance from affecting your published app; without auto top-up, you do run that risk.

Do I need a new subscription for every project? No, your credit balance and subscription apply to your account; multiple projects share the same balance, unless you set per-member limits within a team.

Want to know whether Lovable fits your situation, or need help with a project from idea to launch? Check out Lovable for businesses or Lovable for marketers, or first compare your options at Lovable vs. alternatives. If you're not even sure whether an AI app builder or a classic website is the better fit, take a look at webdesign or websites. For questions about prompting and building effectively, see Lovable prompting. As the Lovable partner in the Brainport region (Eindhoven), we help businesses set this up properly; feel free to get in contact for a call.

Free vs. Pro: when do you switch?

For an initial exploration, Free is more than enough: you can build, prompt and test daily without paying. The limit becomes noticeable once you want to seriously develop a project further: no code download means you can't export to your own repository, and the monthly cap of 30 daily credits starts to pinch once you're actively building several days in a row. Pro removes both limitations and adds rollovers and top-ups, so a busy week isn't immediately a problem.

Business and Enterprise: when is that relevant?

Note: Business credits cost more than Pro credits — for the same number of credits you pay roughly double (from ~$50 instead of ~$25 per month for 100 credits). You are paying for the governance layer, not for more build volume. Business and Enterprise mainly add an organizational layer: governance, per-member limits with more control, and, for Enterprise, custom volume agreements. That's relevant once multiple people or teams within one organization work with Lovable and you want to control who can do and use what, rather than everyone managing a separate individual account.

Worked example: how credits relate to each other

To give a sense of the proportions (not an exact price, see lovable.dev/pricing for that):

Action	Relative credit usage
Small, targeted prompt (e.g. "change this button color")	Low
Adding a new page or component	Medium
Large refactor or rewriting an entire flow	High
Debugging without logs, multiple attempts	High, often avoidable
Cloud usage of an active, published app	Ongoing, scales with users
AI features (chat, text generation) in production	Ongoing, scales with usage

Think of a small internal marketing tool used by a handful of colleagues a few times a week: build usage is the main driver early on, and once it's live, Cloud and AI usage stay modest because traffic and data volume are low. A bigger, customer-facing app with many users, accounts and AI features behaves differently: build usage matters less over time, while Cloud and AI usage become the ongoing, usage-driven part of the bill as the app scales. This worked example is meant to help you set priorities, not as a fixed table of credit amounts.