Your live app shouldn't spend your build credits

What changed at Lovable

On June 13, 2026, Lovable published a post titled “We're simplifying how billing works on Lovable”. It explained that “until now, Lovable workspaces carried two balances: build credits for developing your app, and a separate Cloud and AI balance for everything that happens once it's live”. From then on there is one balance, covering building plus the databases, authentication, file storage, server functions and AI calls a deployed app makes. Workspaces were migrated over the following days (checked September 2026, lovable.dev/blog).

The documentation now says it plainly: Lovable “uses one credit balance for building your app, hosting it and running its built-in backend (Cloud), and AI features your deployed app uses”. And it says what happens at zero. Building stops until credits are available. The published site stays live and its pages keep serving. But “AI features in deployed apps stop working, and apps that rely on the built-in backend (Cloud) can pause” (checked September 2026, docs.lovable.dev).

Lovable calls this a simplification, and for a developer watching one number it is one. The rebuilt usage page shows which project, which member and which model spent what. That is real information. The problem is not the visibility. It is that the two kinds of spending now compete.

Why one balance is the wrong shape for an owner

Think about a clinic whose site has a chat that answers patients. A good week for the clinic is a week with more questions. Under one balance, that good week is also the week the owner cannot afford to change the opening hours on the site, because the customers spent the credits first. The success of the app and the ability to work on it draw from the same pool, so one starves the other.

It also hides the price of a customer. A credit is a currency, and Lovable's docs are clear that different things cost different amounts of it. So an owner cannot say “each answer costs me this much” and set a price for their own users above it. They can only see, afterwards, that the balance went down.

And when it goes to zero, the part of the app the customer touches is the part that stops. The pages keep serving, but the chat, the AI feature and, in some cases, the backend do not. The owner finds out when a customer tells them.

How JustCopy separates the two

On JustCopy, a build is a plan quota. Free is 3 builds a day, Hobby at $9.99 is 5, Starter at $24.99 is 10, Professional at $49.99 is 25, Business at $99.99 is 50. That number is yours every day, and nothing your customers do can reduce it. Hosting is part of the plan. Text, color and section changes on a page the platform built are free and do not count.

What the live app does is metered separately, per unit, in cents, from a prepaid balance. You top it up in $10, $25, $50 or $100 amounts. Your first paid plan comes with a $2 credit so you can see what the features do before you add money. Every charge is a line on your billing page with the unit and the price, and the balance shows in the project menu, so there is never a mystery about where money went.

Each project has a daily spending ceiling, set by default per plan and adjustable in Settings, so a busy day for your visitors stops at a number you chose. When the balance or the ceiling is reached, the metered feature shows a plain line in place of its answer. The site does not go down, and your builds for the day are still there.

What each thing costs

These are JustCopy's prices from the balance today, the same ones printed on the pricing page. A build is not on the list because a build is never metered.

When the app pays you

Because each unit has a price in cents, you can charge your own users for it. JustCopy's price is the floor. You set your price above it, and your users pay from a balance inside your app, funded by top-ups or a monthly plan you define. On each use JustCopy keeps its cost plus 25 % of the markup, and you earn 75 % of it.

The arithmetic is simple. A reply costs 2¢. Sell it at 4¢ and the markup is 2¢, of which 1.5¢ is yours. A story costs $1.50. Sell it at $5 and the markup is $3.50, of which $2.62 is yours on every story a user makes. Earnings accrue as your users use the app and are paid out monthly above $25. From the $99.99 Business plan you can collect through your own Stripe instead and keep the whole markup.

That is the difference in one sentence. Under one shared balance, the customers who use your app spend the budget you build with. Here, the same customers pay for what they use, and a share of it comes to you.

Side by side

Lovable statements are from docs.lovable.dev and the June 13, 2026 post on lovable.dev/blog, checked September 2026. JustCopy prices are from the pricing page on the same date.

A fair word for the other side

One balance is not a trick. If you are a developer who runs several apps in one workspace and reads the usage page every week, a single number that includes everything is convenient, and Lovable's breakdown by project and model is more detailed than most. The point of this post is narrower: an owner with one site and real customers should not have to choose between serving them and working on the site, and should be able to see, in cents, what a customer costs and what a customer pays.

Questions