Lovable grants five build credits a day for vibe coding on its free tier, enough to get something running in a browser by the end of the first evening. It is not enough to finish, and the reason has less to do with the model's writing than with two things the chat window hides: what each instruction costs, and what the generated app leaves open once real people can reach it.
The unit of work is a credit
Every message you send in Plan Mode costs exactly one credit, while Build Mode is priced by complexity. The documentation's own worked examples put a button styling change at 0.50 credits, removing a footer at 0.90, implementing authentication at 1.20, and a landing page with images at 2.00.
Read those numbers against the daily grant and the shape of a free project becomes clear. Five credits a day is two real features, or one feature and three corrections. The Free plan also carries a monthly ceiling: once thirty build credits have gone in a calendar month, the daily five stop arriving until the month turns over. Alongside that, every plan gets twenty Cloud credits and four AI credits a month, which cover hosting, database traffic and any model calls the deployed app itself makes.
Paid capacity is sold in bundles rather than as a flat seat price. Unused monthly plan credits roll over while the subscription stays active and expire two months after they were issued, though the daily build credits and the Cloud and AI grants expire unused.
The practical effect is that vague instructions have a price. A prompt that asks for four unrelated changes at once produces a build you then spend two or three more credits unpicking. Describing one change per message costs more messages and fewer credits.
The stack underneath the chat
What comes out is a real codebase you can read, edit and push to GitHub or GitLab, so nothing here is a black box you rent access to. Knowing which template you got matters for what you can do with it later.
Lovable projects have used both the React with Vite template and TanStack Start, which render pages differently. A React and Vite project sends the browser a mostly empty page and fills it in with JavaScript afterwards. TanStack Start renders each page into finished HTML on the server.
That distinction decides whether a search crawler, a link preview or a reader on a slow connection sees your content at all. If your project still uses the React and Vite template and you care about anything being indexed, migrating is the first thing to do. It carries the design, the content and the backend code across, so nothing needs rebuilding from scratch.
Where a generated app stops being safe
The gap that catches most first projects is not a bug. It is code that works exactly as written and assumes the browser is on your side.
Lovable's own guidance is blunt about this. Secrets stored in frontend code are visible to users and should be considered compromised, client-side authentication checks can be inspected, modified or bypassed and should never be relied on for access control, and Row Level Security needs verifying as enabled on every sensitive table before you publish. That last one carries a timing note worth taking seriously: RLS is far easier to change before real data exists.
Think about what those three warnings have in common. An admin panel hidden behind a check in the browser is hidden from people who do not open developer tools. An API key pasted into a component ships to everyone who loads the page. A database table without a row policy answers any request that arrives with the public key, including one typed by hand.
The app looks correct because it is correct for the person who built it, and the model wrote what it was asked to write.
Work that keeps the bill and the risk down
Four habits change the economics of a Lovable project more than any prompt wording:
- Describe one change per message, and use Plan Mode to think through anything larger before building it.
- Connect Git early, so you can read diffs instead of guessing what a build changed.
- Turn on Row Level Security and check every table before the first real user signs up.
- Move any key, any pricing logic and any validation that matters into server-side code.
The second one pays for itself fastest. Once the project is in a repository, a change you disagree with is a diff you can revert for nothing. A follow-up message costs another credit and may introduce a second problem while fixing the first.
A first month, costed
Take a small booking form as the example: a signup, a table of slots, an email confirmation. Authentication runs about 1.20 credits, a landing page with images about 2.00, and the form and table perhaps four or five between them with corrections. That is most of a free month's thirty-credit ceiling before anyone has used the thing, and the bookings table still needs Row Level Security checked from a signed-out browser tab before the form goes public.