Lovable Free Plan Tested: One Booking App Used Every Credit

If you are a non-technical business owner asking whether Lovable's Free plan is enough to build your booking site or client portal: it will build it once, and then it stops. We tested this on a clean Free account on 2026-09-14. One prompt — a booking app for a fictional career coach, with logins and an admin page — consumed 9.99 credits in about 15 minutes and left us at zero, with the composer replaced by "Upgrade now". The app it produced was genuinely good. We could not change a single thing about it without paying $25/month for Pro.

So: use Free to find out whether Lovable can build your idea at all. Budget for Pro if you intend to finish it.

What we built and how we tested

We wrote a brief for a fictional test business — "Clearpath Career Coaching", a solo online career coach called Dana — and turned it into one starting prompt. The business is invented for testing; the tool behaviour below is not. Full method: how we test.

The prompt was pasted verbatim into a fresh project, no template, no image upload:

Build a website and web app for "Clearpath Career Coaching", a solo career coach named Dana who works online.

Public pages: Home, Services, About, and Book. Services: "Free discovery call" (20 minutes, free), "1:1 coaching session" (60 minutes, $150), and "CV + interview package" (3 sessions, $400). Use a calm, professional design. Do not invent testimonials, reviews, client names or statistics; leave a clearly marked placeholder instead.

Booking: a visitor chooses a service, a date and an available time slot (Monday to Thursday, 09:00 to 17:00, 60-minute slots, in Dana's time zone), then enters their name, email and a short note about their goal. A slot that is already booked must not be bookable again. Save every booking in a database. When someone books, send an email notification to dana@example.com with the booking details, and send the client a confirmation email.

Client accounts: clients can sign up and log in. Logged-in clients see only their own upcoming and past sessions and the notes Dana has added to their sessions. They must never see other clients' data.

Admin: Dana has a private admin page, visible only to her, listing all bookings. She can mark a session as completed, add a note for the client, and export all bookings and contacts as a CSV file.

The site must work well on mobile phones, and each page needs its own SEO title and meta description.

That is roughly what a real small-business owner would ask for: a site, a booking flow, a database, logins and an admin view.

The account was clean. Before the prompt, lovable.dev/settings/billing showed plan "Lovable Free" with two separate balances — Credits: 5 left ("5 credits expire on 14 September 2027") and Daily build credits: 5 left ("Resets at midnight UTC") — and a usage graph reading "No usage in the last 30 days". Everything consumed below is ours.

We sent the prompt at 07:42 UTC. A minute later Lovable paused and asked one question before writing any code — "Which design direction should I build?", with rendered mini-previews and one option pre-selected. We accepted the pre-selected default, which is the least-steering choice available. Then it ran unattended for about fourteen minutes, narrating its own progress ("Reviewing booking flow and data needs", "Setting up routes and pages", "Re-testing the booking flow") and deciding on its own to store admin access as a role in the database.

About 15 minutes of wall clock, one click of human input. Then the money moment.

The paywall arrives after prompt one, not prompt six

The instant the first prompt finished, the message box was replaced by:

0 free credits remaining today · Upgrade now

The billing page immediately after showed, verbatim: "Daily build credits — 0 left — Resets at midnight UTC", and usage over the last 30 days of 9.99 credits, all attributed to this one project. The "Credits — 5 left" row that existed before the prompt was gone from the panel.

One prompt consumed 9.99 credits — both the 5 daily build credits and the 5 signup credits. The entire free allowance of a new account, spent on a single realistic small-business app.

One thing we cannot tell you, because the interface does not show it: exactly how the 9.99 splits between the two pools, or whether the signup credits are gone for good or merely hidden while the daily balance is at zero. What is certain and screenshotted is the before and after: 5 + 5 with zero prior usage, then 9.99 used and nothing left.

This matters because of what the arithmetic implies elsewhere. Lovable's own docs describe the Free tier as 5 daily build credits, capped at 30 a month ("on Free, you receive daily build credits for the first 6 days each month (6 × 5 = 30), then none until the next month starts", docs.lovable.dev, read 2026-09-14). Read as arithmetic, that sounds like several builds a day. Measured against a real app request, it was one build and done.

And at zero, Free has no escape hatch. Per lovable.dev/pricing on 2026-09-14, "On-demand credit top-ups" is a Pro-only line. You cannot buy your way out of the wall on Free — the screen offers Pro at $25/month (or $250/year, which the page presents as $21/month). Business is $50/month.

What the free build actually got right

This is not a story about a bad app. From the single prompt, without follow-ups:

Four real pages, correct content, and no invented testimonials. Home, Services, About and Book, with working navigation and the exact prices from the prompt (free 20-minute discovery call, $150 60-minute session, $400 three-session package). No lorem ipsum. Asked not to invent testimonials, Lovable obeyed and said so on the page, verbatim:

PLACEHOLDER — CLIENT TESTIMONIALS Testimonials, reviews and client outcomes will appear here. This space is intentionally left empty until real, verifiable client quotes are provided — no fabricated reviews.

No invented client names, review counts or statistics appeared anywhere on the site.

Bookings save to a real database. We booked two sessions through the form as ordinary visitors. Both were written to a bookings table, confirmed by reading the table with SQL.

Double-booking is blocked on the server, not just in the interface. Greying out a button proves nothing — anyone can post the request directly. So we captured the app's own server-function request and replayed it by hand. Replayed against an already-booked slot: no row created. The control, an identical replay against a free slot: row created. That control is what makes the result conclusive — the replay technique demonstrably can write, so the duplicate's failure to write is the server refusing it. Final table state: exactly three rows, no duplicates.

Access rules we never asked for. We never used the words "row-level security", "RLS" or "policy". The prompt said only that clients "must never see other clients' data". Lovable enabled row-level security on all three tables and wrote policies where clients can read only their own bookings, admins can read all, and — the part a non-technical owner would never think to check — there is no read policy for logged-out visitors at all, so an anonymous visitor cannot read any booking. It also put roles in a separate user_roles table rather than on the user's own profile row, which is the pattern that stops a user granting themselves admin. Opening /admin while logged out redirected to the login page rather than rendering.

Mobile is clean. At a 360 px viewport the page width matched the screen width exactly — no horizontal scroll. (Recorded honestly: the brief specified 375 px; our automation window could not go narrower than 360 px, which is the stricter test.)

The SEO basics are mostly there, and the pages are real HTML. The server response for /services is 22.8 KB and already contains the title and an H1 — server-rendered, not an empty JavaScript shell. Every page has a unique title and meta description, exactly one H1, Open Graph tags, and a permissive robots.txt with no noindex. The miss: sitemap.xml returns 404.

Two defects you should know about

1. The app tells your client an email is on its way when no email system exists. Lovable was honest in its own summary: "Emails aren't being sent yet. Sending real confirmation and notification emails needs an email domain you own connected to the project; bookings save fine in the meantime." But the app's confirmation screen tells the booker, verbatim: "A confirmation email is on its way, and Dana has been notified." For a coach whose new client sits waiting for a confirmation that will never arrive, that is a business-breaking default — and fixing it costs a follow-up prompt you do not have credits for.

2. A booking can be created while the caller is told it failed. Both of our replayed requests returned HTTP 500 with a generic "This page didn't load" error page — including the one that successfully created a booking. Visitors using the normal form are unaffected; anything calling the endpoint directly can get a false failure. We logged this as observed behaviour and did not investigate the cause.

Two smaller notes: there is no delete policy on any table, so nobody — not even the owner — can delete a booking; a cancellation has to be a status change. And Lovable picked London as Dana's time zone without being told, then labelled it clearly on every page. A reasonable default, honestly disclosed, but a guess.

What we could not test, and why

We are not going to tell you how Lovable performs at things we did not reach. Out of twelve requirements, these were not settled:

• Owner and client notification emails. We control no test inbox, so dana@example.com was left in the prompt as-is. Delivery, sender domain and spam placement are untested.
• Client sign-up and login, and the admin page. Signing up requires confirming an email, and with no inbox no account could be created — which also means no admin user could exist, so the admin view and CSV export were unreachable. The behavioural isolation test (client A trying to reach client B's data by editing IDs and URLs) is therefore untested; only the access rules above were verified.
• Custom domain and HTTPS. Custom domains are Pro-only on Lovable, per its docs on 2026-09-14.
• Page speed scores. These need a public URL, and we did not publish the test app.
• Editing after launch. The budget allowed twelve follow-up prompts. The free tier ended after prompt one, so nothing was attempted. On Free you do not get a single follow-up.

Who the Free plan is for

Use Free if you want to find out, in a quarter of an hour and for nothing, whether an AI builder can produce the app in your head. It is a full-quality sample, not a crippled demo: real database, real access rules, real pages. That is a genuinely useful answer to have before you spend anything.

Do not plan to finish on Free if your app needs email, logins you can actually use, a custom domain, or any change at all after the first generation. Each of those needs at least one more prompt, and after a build of this size there are no credits for one. The honest paid trigger is not "when you scale" — it is the first fix you want to make, usually within minutes of the first build.

What to do about the credit wall. Free credits reset daily (Lovable's docs describe daily build credits for the first six days of each month), so one option is to come back tomorrow and spend the next day's allowance on one fix. If your app matters, the realistic path is Pro at $25/month, which is also the only tier that can buy top-up credits or connect your own domain.

Alternatives, stated honestly

We have not yet run this same build in any other tool, so we will not rank them. For reference only, with prices read on 2026-09-14: Base44 lists a Free tier at $0 with 25 message credits a month and authentication plus a database included, and a Starter plan at $16/month billed annually. We will publish the same twelve-requirement build for other builders as we complete them; until then, treat that as pricing information, not a recommendation.

If you want to see the standard we hold every tool to before we recommend it, read how we test and our other reviews.

Prices and product behaviour checked on 2026-09-14 on a Free account. We earn a commission if you buy through our links, at no extra cost to you — see our affiliate disclosure.