Lovable review: six requirements, six passes, 109 seconds

Is Lovable worth it?

L

Yes. This Lovable review rests on a single measured build, so here is the result first: it does the thing the category promises, a prompt in and a working application out, and it does it more precisely than I expected.

I gave Lovable one prompt containing six numbered requirements, two of which were written specifically to be fumbled: a price that has to be derived rather than displayed, and a list item that must leave the total without leaving the page. It satisfied all six on the first attempt, in 109 seconds, with no follow-up prompts. That is a different kind of result from what I get out of a terminal agent working in an existing repo, and a different kind of bill. Then it made two design decisions I had not asked for and would have asked for next.

That is the strongest prompt-to-app result I have measured. I want to be equally precise about how narrow the evidence is: one greenfield single-page app, one prompt, free tier. Nothing here tells you how it behaves on prompt fifteen or against a repository that already exists.

Alley Rating: 4.6 / 5 — Category Leader.

What does Lovable actually do?

Lovable AI takes a description of an application in plain English and builds one, end to end, on a live URL. That is the whole pitch, and the interface is built to keep you from doing anything else.

The dashboard is a single prompt box that greets you by first name and asks what is on your mind. Six starting chips sit beneath it (Website, Community, Landing page, Internal tool, Dashboard, Store), with a row of templates below the fold. There is no file tree, no terminal, no editor. The sidebar carries Projects, Search, Resources and Connectors, and that is the extent of the chrome.

Once a build starts, the screen splits: your conversation on the left, a live preview of the running app on the right. The preview is real and interactive rather than a screenshot: I clicked through mine, typed into its forms and reloaded it. It runs on its own subdomain, which means you can open it in a normal tab, and mine carried a small “Edit with Lovable” badge in the corner that paid plans remove.

Three details that tell you what the product is actually for:

Build mode and Plan mode. A dropdown in the chat box switches between them, and Lovable’s own tip explains why: Plan mode lets you brainstorm or debug without code changes. Read that precisely, because I did not at first. It means Plan mode will not touch your app, not that it is free. Lovable’s own documentation is explicit that every Plan mode message deducts one credit. What it saves you is the variable cost of a build you did not want, at a flat one credit a message.

Follow-up suggestions. After my build it offered four next steps — add edit-subscriptions, import and export data, add sorting, show a monthly spend breakdown. Each is one click and each costs credits, which is a very well-designed funnel.

Comment-based feedback. A prompt offered to collect comments on the preview from anyone, explicitly noting that no Lovable account is needed to comment. That is aimed squarely at the non-technical founder showing a prototype to three people before building anything real.

The features that decide whether a prototype becomes a product (GitHub sync, Supabase-backed data, custom domains, publishing) all sit on paid tiers, and I stayed on the free one.

What did I ask Lovable to build?

Most reviews of this category describe the output. I wanted a test where the tool either passes or fails on each point, so I wrote the prompt as a numbered list and then used the app rather than reading Lovable’s summary of it.

The brief: a single-page subscription tracker called Stack Cost, with (1) add a tool with name, cost and billing cycle, (2) annual plans must display a monthly-equivalent cost rather than the annual figure, (3) a running monthly total pinned at the top, (4) a cancelled state that removes an item from the total but keeps it visible in its own section, (5) persistence across reloads via localStorage, and (6) a dark theme.

Requirements 2 and 4 are the interesting ones. Both require the tool to hold two ideas at once — a stored value and a derived one, a list that is filtered for maths but not for display — and both are the kind of instruction that gets flattened into something simpler.

Six for six. Then it did two things I had not asked for: cancelled rows gained a Restore button, and the annual price stayed visible as sub-text beneath the monthly-equivalent headline rather than being discarded. Both are what I would have asked for on a second pass.

I checked the persistence claim in the browser console rather than trusting the reload, and what it stored turned out to be more interesting than whether it stored anything at all. I come back to that below, once the cost of a build is on the table.

How should you write the prompt?

Write it as a numbered list of checkable requirements, state any value that has to be derived rather than displayed, describe behaviour instead of implementation, and name the storage mechanism if it matters. That discipline is what kept my build to a single attempt, and on a metered plan a single attempt is the whole ballgame. Here is exactly what I sent, unedited:

Build a single-page app called Stack Cost that tracks AI tool subscriptions.
Requirements: (1) add a subscription with name, cost in USD, and billing cycle
of monthly or annual; (2) annual subscriptions must display a monthly-equivalent
cost, not the annual figure; (3) a running total of monthly spend pinned at the
top; (4) each subscription can be marked cancelled, which removes it from the
total but keeps it visible in a separate Cancelled section; (5) all data
persists in localStorage across reloads; (6) dark theme throughout.

Four things about that prompt are deliberate, and all four are transferable to any tool in this category.

It numbers the requirements. Not for the tool’s benefit particularly, but for mine — a numbered list is checkable afterwards. “Build me a subscription tracker” produces something you can only assess by vibe, and vibe is how people end up burning a day’s credits discovering they wanted something else.

It states the derived value explicitly. Requirement 2 does not say “handle annual plans”, it says annual plans must show a monthly-equivalent figure rather than the annual one. That is the difference between a requirement and a hope. Ambiguity here is what produces an app that stores $2,400 and displays $2,400.

It describes behaviour, not implementation. Requirement 4 says cancelling removes an item from the total but keeps it visible. It does not say how — no mention of arrays, filters or components. Lovable chose to compute the monthly figure at render time and keep the raw annual value in storage, which is the right call and not one I made for it.

It names the storage mechanism. Requirement 5 says localStorage specifically. This is the one place I did specify implementation, because “saves your data” could mean anything from a cookie to an account system, and the difference is the entire cost of the build.

The result was one build, no follow-ups, 1.20 credits. My honest read is that a vaguer version of the same request would have cost three or four times that in iteration — which makes prompt discipline the habit that saves you most on a metered plan, and an odd thing to need from a product sold to people who do not want to think like engineers.

How much does Lovable cost?

Lovable does not charge by time, it charges by credit, and this is the part worth reading twice. Every figure below is off Lovable’s own pricing page, checked on 5 August 2026.

Annual billing is advertised as two months free, and students can get up to 50% off Pro.

Now the arithmetic nobody puts in a review. My six-requirement app cost 1.20 credits. Lovable’s own published examples line up with that: a simple update is 0.50, removing a component 0.90, implementing authentication 1.20, a landing page with images 1.70.

So on Pro’s 100 monthly credits, a build the size of mine is about 83 a month, or about thirty cents each. That sounds enormous, and it is misleading, because almost nobody builds an app in one prompt and stops. The credits disappear during iteration — the fourth attempt at getting a layout right costs the same as the first. That is the opposite shape to a capped subscription like Claude Code’s monthly plans, where the plan price is the ceiling and running out means waiting rather than paying.

One thing worth reading carefully, because I got it wrong first. The workspace menu shows a single credit number, and mine said ten before the build and 8.80 after. I took that ten for the daily grant, which would have made the published figure of five wrong. It is not. The billing page splits the same balance into two buckets: five daily build credits that reset at midnight UTC, and five one-off bonus credits that sit there until they expire in 2027. My 1.20 came out of the daily bucket, taking it to 3.8 and leaving the bonus five untouched.

What is the catch with Lovable credits?

Two things about credits will cost you money if you learn them late.

They expire. Lovable’s pricing page puts it plainly: monthly plan credits expire two months after they are issued, annual plan credits one month after the annual period ends, top-ups after twelve. Buying a big balance to cover a busy quarter is a worse idea than it sounds.

A wrong answer bills twice. A build action costs the same whether you keep the result or not, so the expensive way to use Lovable is to discover your requirements through conversation. Use Plan mode for anything exploratory, at a flat one credit per message, rather than discovering through builds that cost a variable amount each. And ignore the one-click follow-up suggestions unless you actually want that feature.

That is the whole of the cost story, and I have given it two sections rather than six because the more interesting question for a tool in this category is whether the app is any good. If metered billing is the part that worries you, it is worth knowing it bites in editors too: my Cursor review tracks what eleven months of it actually cost.

How good was the app it built?

The checklist says six for six. That undersells it, and the places it undersells it are the ones that tell you what this tool is actually doing.

It understood which number was derived. I asked for annual plans to show a monthly-equivalent cost. It rendered $200.00 /mo as the headline and kept Annual · $2,400.00/yr beneath it as context — which is not what I asked for and is what I should have asked for. Losing the annual figure entirely would have satisfied the brief and produced a worse app.

It stored the right thing. I checked the browser console rather than trusting the reload. The data sits under a namespaced key, stack-cost:subscriptions, and holds the raw annual figure alongside the billing cycle. The monthly equivalent is computed at render. That is the difference between a tool that satisfies a requirement and one that models the problem: had it stored the derived $200, editing the plan later would have been lossy.

It invented the missing verb. I specified that cancelling removes an item from the total but keeps it visible. I did not specify how to undo that. It added a Restore button. That is the obvious next requirement and I did not have to spend a second prompt on it.

The interface was finished, not sketched. Cancelled rows are struck through and dimmed rather than merely relocated. The total reads “per month across 1 active tool” and pluralises correctly. The empty state says “No active subscriptions yet” rather than showing a bare zero. None of that was in the brief.

Where it stops is equally clear. This is a single page with browser-local storage: no accounts, no backend, no sharing between devices. The moment it needs to be shared, it needs infrastructure I never asked Lovable to build. That boundary is where the prompt-to-app promise gets tested properly, and I did not take it there.

Is the free tier enough to decide?

Yes, and that is worth saying clearly because it is unusual.

I built and stress-tested a working application without entering a card, and I still had 8.80 credits left afterwards: the five bonus credits untouched, and 3.8 of the day’s five still to spend. The daily bucket alone was good for three more builds the size of mine before midnight, with a fresh five arriving tomorrow, and the bonus five sitting on top of that for whenever I wanted them.

Two limits to know before you plan around it. Credits do not accumulate on the free tier the way they roll over on Pro, so an unused day is simply gone. And the free tier keeps the Lovable badge on your preview, which is fine for testing an idea and not for showing a client.

What the free tier is genuinely good for is answering one question: does this tool understand what I ask it for? That took a single build, and the answer was yes.

Who is Lovable for?

Lovable is for people who need a working application before they need a codebase: founders validating an idea, marketers who want a real page instead of a mockup, and teams whose internal tool has been stuck behind an engineering queue for a quarter. It is the wrong instrument if you already have a repository, or if a predictable monthly bill matters more to you than speed.

The good

It respects a specification. This is the finding I did not expect. Six constraints, including two designed to be fumbled, all satisfied without a follow-up. Adherence is a better signal than raw capability, because a tool that half-reads your prompt costs you the credits twice.

It is genuinely fast. Under two minutes from prompt to a working, interactive app on a live URL. Not a mockup, not a code dump — something I clicked through and stress-tested.

The free tier is real. I built and tested the whole thing without entering a card. That is not universal in this category, and it makes the evaluation cost you nothing but time.

It makes sensible unasked decisions. The Restore button and the retained annual figure are small, but they are the difference between a tool that parses instructions and one that understands the job.

The bad

Credit anxiety is a real cost. Knowing every attempt has a price changes how you work. I found myself over-specifying the prompt to avoid a second round, which is rational and is also the opposite of the fast, loose iteration the category is sold on.

The evidence stops at the blank page. Everything above describes greenfield work. I have no data on how it behaves against an existing repository with existing conventions, which is where most real work lives and where editor-based tools are known to struggle.

The balance you are shown is not the balance that refreshes. The workspace menu surfaces one combined credit number, which is why I spent a while believing my daily grant was double the published one. It is not, but only the billing page will tell you that. Only the billing page tells you which part resets tonight and which part is a one-off. In a product whose main variable is consumption, the number in the most glanceable place should be the number that matters.

The community is harsher than the review sites. The review blogs average it above 4.5; the Reddit threads include a prominent argument against using it for production apps at all. The gap is about operations — proprietary hosting, debugging code you did not write — rather than about whether it builds working software. It builds working software.

What do other Lovable reviews say?

There is an unusually wide gap here, and it is worth understanding before you weigh anyone’s rating including mine.

Trustpilot is the first thing you find when you look Lovable up, ahead of every editorial page, which tells you what people are really asking: is Lovable legit? The review blogs put Lovable between 4.5 and 4.8 out of 5, one of them aggregating fifteen G2 and Capterra entries in which every single reviewer said they would recommend it. The Reddit threads sitting alongside them are considerably harsher: one popular r/lovable post concludes flatly that the author does not recommend the product, and another argues against using it for production apps at all.

The gap is not really about whether the software works. Read the complaints and two themes dominate, and neither is “it produced broken code”. The first is support. The second is the credit system — and specifically that fixing a bad output costs credits, so a wrong answer is billed twice.

That second complaint is corroborated on G2, where a mid-market reviewer who rates the product 4.5 still writes that a stuck “Try to fix” loop can chew through ten or fifteen credits without producing a fix, and that support is the weakest part of the experience. It also lines up exactly with what I found from the opposite direction: my build was cheap because it was right first time. Nobody who gets it right first time complains about the meter.

So the honest synthesis is that Lovable’s output quality and Lovable’s cost model are separate questions, and most negative reviews are about the second one. My measured build speaks to the first and says good things. It says almost nothing about what happens on prompt fifteen.

How does Lovable compare to the coding agents?

Worth being clear that Lovable is not competing with the tools I usually write about, even though they get compared to each other constantly.

Claude Code, Codex and Cursor are for working inside a codebase you already have. Lovable is for not having one yet. The correct comparison is not which produces better code, it is which problem you have today — and if your answer is “I have a repo”, none of what I measured above is relevant to you.

The one axis where they genuinely compare is billing shape. A coding agent on a capped plan bills you a flat fee and stops unless you opt into overflow credits; Lovable bills per action and stops when your credits run out. Both have a ceiling, which puts Lovable in better company than Cursor’s metered model, the one I left after eleven months and $510.70.

What are the best Lovable alternatives?

Three, and which one fits depends on a question Lovable’s marketing does not ask you: do you have a codebase already?

Replit is the closest competitor in shape — prompt-to-app, hosted, with the same non-technical audience in view — but it carries a full IDE and a real terminal alongside the agent. That makes it the better choice if you expect to end up editing the code yourself, and the worse one if the absence of an editor is precisely what you liked about Lovable. I have since put it through this same six-requirement build: the Replit review has the numbers, and it matched Lovable six for six while taking about twice as long.

Bolt occupies the same prompt-to-app slot and runs its whole toolchain inside the browser tab. I have since given it this same six-requirement brief: the Bolt review has the numbers, and it matched Lovable six for six while producing the more finished app. It is the one to weigh if you want the fullest first draft, and the one to be careful about if you buy on reputation, because its customer reviews are far harsher than its press.

Claude Code is the answer if the honest description of your problem is “I have a repository.” It is a terminal agent rather than a builder, and it bills as a capped Claude subscription at $20, $100 or $200 a month before tax rather than a per-build meter, with optional usage credits if you choose to push past the cap. It is what I use daily, and I wrote up whether it is worth it separately. It will not give you a hosted app from one sentence, and it will work inside code that already exists, which Lovable is not built to do.

If the cost shape rather than the category is your worry, the wider coding-tool comparison covers what capped plans and metered plans each do to a monthly bill.

What did I not test?

The rating above is only as good as its evidence, so here is the boundary in one list:

• Paid tiers. Everything here is the free plan.
• Iteration at length. One prompt, no follow-ups — which means I never entered the scenario that dominates the negative reviews.
• Anything with a backend. No auth, no database, no third-party API.
• GitHub sync and publishing. The features that decide whether a prototype becomes something you own.
• Existing codebases. Not what the product is for, but worth stating.

The final word

Lovable did the thing it claims to do, and it did it precisely rather than approximately. Six requirements, six passes, 109 seconds, one prompt — and an app that was better than the brief in two places I had not thought to specify.

That is the finding. A tool in this category lives or dies on whether it understands what you asked for, and on this test it understood a derived value, a filtered-but-visible state, and a missing verb I never mentioned. The output was not merely working, it was well modelled.

What I cannot tell you is what happens next: on prompt fifteen, with a database attached, with a second user. Every serious criticism of this product lives in that territory, and one afternoon does not reach it.

4.6 out of 5. The deduction is for the metered model, which charges the same for a wrong answer as a right one and makes the tool cheapest for the users least likely to be precise — a real design flaw, not a preference. The consistent community complaints about support cost it a little more.

What the score does not do is punish the product for the size of my test. That was my earlier instinct and it was wrong: an evidence base of one app is a limit on my confidence, not a defect in the software, and it belongs in the paragraph above rather than in the number. On what I measured, this is the best prompt-to-app result on the site.

One honest caveat on the badge. Lovable holds the top slot in our app-builder category on its overall standing, not on the strength of this session, and my test was kind to it by design: one careful prompt is the scenario the product handles best, and precisely the one the harsher reviews are not complaining about. Treat the label as provisional until I have run it through the messy case.

I would pay the $25 on this showing. I would still want a paid month and fifty prompts before telling anyone to build a business on it.