Lovable does not charge per seat or per hour. It charges in credits, and a credit is consumed by sending a message that does work - which makes estimating a month harder than reading a price list.
Credit-based pricing is increasingly common for AI products and it is genuinely difficult to reason about, because the unit is not a thing you can count in advance. Here is the model as documented at the time of writing, and a way to estimate what a month costs you.
Table of contents
- The credit model
- What a credit buys
- The plan ladder
- Estimating a month honestly
- When the model fits and when it does not
- How this fits the rest of the stack
- FAQ
The credit model
One credit balance covers three separate activities: building the app by prompting, hosting it with the built-in backend, and AI features that your deployed app offers to its own users.
Bundling all three into one balance is the design decision that makes the model hard to predict. A heavy building month and a heavy traffic month draw from the same pool, so the balance you sized for development gets consumed by usage once the app is live.
Credits arrive from two sources. Monthly plan credits land at the start of each billing period. Daily grants land every day and are capped at a monthly total. On paid plans the daily grants add up to a meaningful fraction of the total, which is easy to miss when comparing the headline plan numbers.
Expiry rules apply. Monthly plan credits carry an expiry measured from the issue date, and purchased top-up credits have their own longer validity. If you are buying credits in bulk against future work, check the window before assuming they will still be there.
What a credit buys
The documented rate is per message, varying by how much work the message causes. The published examples give a rough sense of scale:
- A small styling change, such as recolouring a button - well under one credit.
- Removing a component - still under one credit.
- Adding authentication with sign-up and login pages, including route changes - a little over one credit.
- Generating a full landing page with images, a theme, and several sections - closer to two credits.
There is also a planning mode charged at a flat one credit per message, which is worth knowing because it changes how you should work. Thinking out loud in planning mode costs the same regardless of the size of what you are planning, while executing costs in proportion to the change.
The practical implication is that iteration is the expensive pattern. Five rounds of small adjustments cost more than one well-specified request that lands correctly, because each round is a message. The cheapest way to use a credit system is to think first and prompt once - which is also, usefully, how you get better output.
Note that these figures are examples rather than a rate card, and the actual cost of any given message varies with what the model has to do. Treat them as an order of magnitude, not a calculator.
The plan ladder
At the time of writing the structure is a free tier, a Pro tier, a Business tier, and an Enterprise arrangement.
Free provides a daily build-credit grant with a monthly ceiling, plus a separate monthly grant for the hosted backend and a small allowance for AI features in deployed apps. Projects are private and collaborators are unlimited within the workspace. What it does not include is the set of things you need to ship publicly: custom domains, removing the platform badge, and direct code editing.
Pro is the individual and small-team tier, around $25 a month for a hundred monthly credits, and it unlocks custom domains, badge removal, code mode, credit rollover, and top-ups. With daily grants on top, the effective monthly total is meaningfully higher than the headline hundred.
Business roughly doubles the monthly price for the same headline credit count, so the credits are not what you are buying. The value is administrative: per-member credit limits, unlimited users, and additional controls. That matters once several people share a balance and one enthusiastic prototyper can consume the team’s month.
Top-ups are available on paid plans, priced per credit above the plan rate. Buying credits in top-ups is more expensive per credit than moving up a tier, so if you consistently exceed your allowance the tier upgrade is the cheaper path.
Estimating a month honestly
Credit systems resist estimation, but a rough procedure gets you close enough to decide.
- Separate building from running. Estimate the credits to build the thing, then estimate what serving it consumes monthly. The second number is the one that persists.
- Count messages, not features. A feature is several messages, and revisions are messages too. A realistic multiplier on your first guess is two to three.
- Budget a learning period. Early prompts are less efficient. The first project costs noticeably more credits than the third.
- Watch the AI-feature line separately. If your deployed app offers AI features to its own users, that consumption scales with your traffic, not your development. This is the line that surprises people.
- Run one real month before committing annually. Usage-based pricing is only predictable once you have your own data.
The structural risk worth naming: with hosting and end-user AI features drawing from the same balance as building, a successful launch increases your bill through a mechanism you did not directly control. That is not unique to this product - it is inherent to bundling usage and development into one currency - but it is worth planning for rather than discovering.
Prices, credit rates, and grants in this space change frequently. Everything above reflects the documented model at the time of writing; check the current pricing page before making a decision on the numbers.
When the model fits and when it does not
Credit pricing is a good fit for bursty, exploratory work. Prototyping, validating an idea, building an internal tool - all of these have a natural end, and paying in proportion to how much you built is reasonable.
It fits less well once an application is stable and serving steady traffic. At that point you are paying a variable rate for a workload that is not varying, and the thing you want is a predictable monthly figure for a known amount of compute and storage.
That is the natural handover point, and it is worth recognising when you reach it. An application with a settled feature set, its own database, and real users is a hosting question rather than a building question, and hosting is priced in vCPU, RAM, and bandwidth - units you can forecast because they do not depend on how many messages you sent this month.
On RunxBuild, a web service runs on a plan you pick, from a Free tier through Dev at $4 and Basic at $6 up the ladder as the workload grows, with a managed Postgres or MySQL beside it and autoscaling between a floor and ceiling you choose. The number is the number, whether you deploy once this month or forty times.
How this fits the rest of the stack
The moment credit pricing stops fitting is the moment the app is stable and the traffic is real, because that is when you want a figure you can forecast. The RunxBuild hosting calculator shows exactly that: the service, the managed database, storage, and bandwidth as separate line items on one page. Push a repo, get a build log and a live route, and scale between plans you pick rather than watching a balance.
Useful related references:
- GCP vs AWS: Pricing, Network, and When to Pick Each
- AWS vs GCP: Pricing, Network, and When to Pick Each
- Hostinger vs Bluehost: Reading Shared Hosting Pricing Honestly
- Services on RunxBuild
FAQ
How does Lovable’s credit pricing work?
One credit balance covers building the app by prompting, hosting it with the built-in backend, and AI features your deployed app offers its own users. Credits arrive as monthly plan credits plus daily grants capped at a monthly ceiling, and they carry expiry windows measured from the issue date.
What consumes a credit?
Sending a message that causes work. The cost scales with the size of the change - a small styling tweak is well under one credit, while generating a full page with images is closer to two. Planning-mode messages are charged at a flat one credit each regardless of scope.
Is the Business plan worth double the Pro price?
Only if you need the administrative features. Both tiers carry the same headline monthly credit count, so you are not buying credits - you are buying per-member credit limits, unlimited users, and additional controls. That matters once several people draw from one shared balance.
Are top-up credits cheaper than upgrading a plan?
No. Top-ups are priced per credit above the plan rate, so if you consistently exceed your allowance, moving up a tier costs less per credit than repeatedly topping up. Top-ups are for occasional overruns, not sustained usage.
What is the hardest part of budgeting for credit pricing?
That building and running draw from the same balance. Development consumption ends when the feature ships; hosting and end-user AI consumption scale with traffic and continue indefinitely. A successful launch therefore increases your bill through a mechanism you did not directly trigger.