Lovable Pricing in 2026: What Shared Credits Mean for Your MVP
Lovable now uses one credit balance for building, Cloud, and in-app AI. See current plans, top-up costs, production risks, and the exit rule.
Lovable's $25 Pro plan is still a strong way to prototype, but its June 2026 billing change makes one number more important than the subscription price: every build, Cloud workload, and in-app AI feature can now draw from one credit balance. Use Lovable to prove the workflow; scope the production MVP before real users, data, and revenue depend on a variable pool that can pause when it reaches zero.
The verdict: pay for the prototype, scope the product
Buy Pro when you are actively proving one workflow; buy Business only when governance is the requirement. Both start with 100 monthly credits, so the extra $25 for Business does not buy twice the building capacity. It buys controls such as SSO, internal publishing, a security center, team workspaces, design templates, and priority support.
Lovable is a conversational web app builder: you describe a change, and its agent plans or edits the project. The value is speed from idea to an interactive reference system. That makes the $25 Pro plan useful for a founder testing whether users understand a workflow, whether the data model is coherent, and whether the product deserves a serious build.
The wrong purchasing question is, "Can Lovable generate this screen?" The right question is, "What must remain dependable after the screen exists?" Once a product carries real customer data, revenue, permissions, integrations, or support obligations, the cheap prompt is no longer the unit of risk. The system around the prompt is.
One balance now covers building and running
Lovable unified billing, not the underlying costs. On June 12, 2026, Lovable announced that purchased build, Cloud, and AI balances would move into one general credit balance. The company kept plan prices, credit costs, consumption rates, daily build grants, and expiry rules unchanged. The practical change is that general credits can now move across three jobs:
Lovable applies usage-specific grants first. Free, Pro, and Business currently include 20 Cloud credits and 4 AI credits each month. They also receive 5 daily build credits; Free stops receiving that daily grant after 30 credits in a calendar month, while Pro and Business do not have a monthly cap on it. After the relevant grant is exhausted, the shared general balance takes over. The current credits documentation is the useful source of truth because it also explains which balance expires first.
That order matters. Imagine a Pro workspace that is quiet during validation, then gets a launch-day traffic spike while the team is still asking the builder to fix issues. Cloud and AI use their specific grants first. Any further run usage and new build work can then draw from the same 100-credit general pool. A single dashboard is easier to read, but the common pool creates a new operating dependency: experimentation and live service continuity can compete for the same fallback credits.
Lovable now shows spend by member, project, Build, Cloud, AI, and AI model in Plans & credit usage. Treat that page as a product cost ledger, not a subscription receipt. A $25 invoice tells you the entry price. The usage split tells you whether the product is becoming more efficient or simply consuming more prompts and infrastructure.
Lovable pricing plans in 2026
Pro is the default founder plan because it buys the same 100 base credits as Business at half the entry price. Free is a trial environment, Business is a governance purchase, and Enterprise is an organizational rollout.
Annual billing lowers the displayed entry rate: Pro is $250 per year, shown as $21 per month, and Business is $500 per year, shown as $42 per month. Do not take the annual discount before the prototype has survived a complete validation cycle. The savings are real, but they are small compared with paying for a tool after the team has chosen a different production path.
Both paid plans scale far beyond the entry tier. Pro runs from 100 to 10,000 monthly credits at $25 to $2,250 per month. Business covers the same 100 to 10,000 range at $50 to $4,300 per month. The widening difference is a useful reminder: Business prices governance into every credit tier.
All plans support unlimited users, so Lovable is not charging per seat. This is good economics for collaboration, but a shared pool needs control. Pro and Business include per-member monthly credit limits. Set them before inviting a broad team, otherwise an unlimited-user benefit can become an unlimited-demand problem.
How Lovable credits burn in practice
A credit is not a fixed unit of completed product work. Plan mode costs 1 credit per message and does not change code. Build mode is variable: small focused edits tend to cost less, while broad generations, codebase exploration, verification, browser checks, web search, and image generation can cost more.
The vendor's current examples show the shape of that variability:
Those three requests total 2.60 credits in the illustrative examples. The sum is useful for comparison, not forecasting. A real authentication change can touch routing, email delivery, permissions, existing data, error states, and tests. The same sentence can therefore represent different work in different codebases.
Here is the practical workflow for a founder. Use Plan mode to narrow the change before asking Build mode to act. Replace "improve onboarding" with a bounded acceptance test: a new user can create an account, verify the account, complete the one core setup task, and return to the correct state after signing back in. You are still paying for planning messages, but you reduce open-ended implementation passes.
Cloud and in-app AI need separate attention even though they share the fallback pool. Cloud rises with database size and activity, network traffic, stored files, compute, and realtime events. AI gateway use rises with model choice, prompt context, output length, and calls per user. A calm build ledger can therefore hide a growing run ledger. Review Run credits by project, then inspect Cloud and AI separately before deciding that the plan is stable.
The auto top-up math controls the real budget
Cap auto top-up before live usage, because the default monthly limit is materially larger than the entry subscription. Pro top-ups cost $15 per 50 credits, or $0.30 per credit. Business top-ups cost $30 per 50 credits, or $0.60 per credit. Purchased top-up credits last 12 months.
When auto top-up is enabled, the documented defaults add 100 credits when the balance reaches 25 credits, with a calendar-month ceiling of 400 added credits. At those defaults, the possible extra monthly charge is $120 on Pro or $240 on Business. Add the base plan and the exposure becomes $145 for Pro or $290 for Business in a month. These are ceilings under the enabled default settings, not predictions of normal usage.
The fix is a budget policy, not a larger plan chosen on instinct.
Separate build and run demand
Open Usage details and compare Build credits with Run credits by project. Review a 90-day range when available so one launch spike does not become the forecast.
Choose the failure behavior
Decide whether a depleted balance should pause work or trigger a purchase. If a live app cannot tolerate interruption, auto top-up may be appropriate, but the limit needs an owner and an alert path.
Set the smallest safe cap
Lovable lets you select refill amounts from 50 to 1,000 credits, trigger thresholds of 25, 50, or 100 credits, and monthly limits from 100 to 25,000 credits or no limit. Pick the smallest combination that covers observed run demand plus a deliberate buffer.
Review the cause before raising it
If the limit is repeatedly reached, identify whether the cause is product adoption, inefficient infrastructure, expensive in-app AI, or build churn. Only the first cause is automatically good news.
There is also a continuity issue. When no applicable credits remain, building stops and deployed apps that rely on Lovable Cloud or AI features stop responding to new requests until credits or grants become available. That makes the balance part of production operations. Someone must own it in the same way someone owns uptime alerts, payment failures, and backups.
Stop prompting when the workflow is proven
Move from tool-led iteration to production scoping before the prototype becomes the unreviewed system of record. The trigger is not a particular number of credits. It is a change in what failure costs.
Four signals mark that boundary:
- The core workflow has held steady. Users understand the same input, transformation, and outcome. More prompts are polishing a known product rather than discovering it.
- Fixes create adjacent failures. A request to repair one state changes another route, permission, or integration. That is a code and architecture review problem, not a prompt wording problem.
- Real operations depend on the app. Customer data, payments, permissions, scheduled work, or support commitments now pass through it. Recovery, auditability, and error handling belong in scope.
- Run cost is becoming hard to explain. Cloud or AI consumption rises without a clear unit such as active account, completed workflow, or paid transaction. The product needs an economic model before it needs more credits.
Consider two founders. The first is showing an investor a scheduling flow with sample data. Pro is a rational expense: speed and editability matter more than production controls. The second is inviting paying teams into the same flow, storing their records, and sending automated work to external services. That founder needs explicit authorization rules, environment separation, data migration and recovery plans, monitoring, and a tested deployment path. A generated interface is useful input to that scope, but it is not the scope.
Code ownership makes the transition possible. Lovable says customers own their project code, and its GitHub integration supports export and two-way sync with github.com on all plans. A linked project can use branches and pull requests, developers can work locally, and the code can deploy outside Lovable. Paid plans can also download the codebase directly. Use the Lovable GitHub handoff checklist before the repository becomes difficult to audit.
Then scope the product from behavior, not from the generated file tree. Define the one workflow that earns the launch, the users and permissions it needs, the external systems it touches, the data that must survive, the failure states that need a response, and the evidence that marks completion. Our guide to a vibe-coded MVP without rewrite debt explains how to keep the prototype useful without letting accidental structure dictate the production architecture.
A founder's shared-credit operating checklist
Run Lovable like a metered prototype environment, with a visible handoff path from the first useful build. This checklist keeps the tool cheap without asking it to carry risks it was never scoped to own.
- Write the core workflow as one input, one transformation, and one valuable outcome.
- Start on Free; move to Pro only when the daily cap blocks real validation.
- Choose Business only when SSO, internal publishing, security controls, templates, or departmental governance are requirements.
- Set per-member credit limits before inviting the wider team.
- Review Build and Run credits separately by project.
- Turn on auto top-up only with a named owner, a deliberate trigger, and a finite monthly cap.
- Connect GitHub before the prototype contains decisions you cannot afford to lose.
- Keep secrets, data exports, third-party accounts, and deployment access under company ownership.
- Record every place where the prototype relies on generated assumptions about permissions, data, or failure handling.
- Scope production when the workflow stabilizes, not when the credit balance becomes painful.
The durable idea is simple: Lovable is inexpensive when it is helping you learn. It becomes strategically expensive when prompt spend hides product uncertainty or a shared balance becomes part of service reliability. Keep buying learning until the workflow is clear. Then buy a scope you can price, build, test, and own.
How much does Lovable cost per month?
Free costs $0. Pro starts at $25 per month for 100 monthly credits, and Business starts at $50 per month for 100 monthly credits. Enterprise uses a platform fee and volume-based credit pricing.
How much is Lovable per year?
The entry Pro tier is $250 per year, displayed as $21 per month. The entry Business tier is $500 per year, displayed as $42 per month. Validate the workflow before taking the annual plan solely for the discount.
Does Lovable give you 5 credits a day?
Free, Pro, and Business include 5 daily build credits. Free is capped at 30 daily-grant credits per calendar month; Pro and Business have no monthly cap on that daily grant. Unused daily credits expire at the end of the day.
What happens when Lovable credits run out?
Building stops. Deployed apps that depend on Lovable Cloud or AI features can also stop responding to new requests until a top-up, auto top-up, or refreshed grant makes credits available.
Do Lovable credits roll over?
Unused paid monthly plan credits can roll over while the subscription remains active, but monthly-plan credits expire 2 months after issue. Top-up credits last 12 months. Daily build grants and monthly Cloud and AI grants do not roll over.
Is Lovable worth paying for?
Pro is worth paying for when it shortens the path to a validated, handoff-ready workflow. It is poor value when repeated prompts are compensating for unclear scope, unstable architecture, or production obligations that need deliberate engineering.
Book the Scoping Sprint
Turn the validated Lovable workflow into a fixed production scope, risk map, and build plan before live usage owns the budget.
Jul 14, 2026
