Lovable vs v0: two units of work, one gap

Lovable builds applications. v0 builds interfaces. Everything else that separates them follows from that one line, including the pricing, the workflow and the kind of person each one suits.

v0 is made by Vercel. Its free plan is $0 a month with $5 of included monthly credits and a 7 message per day limit, and it includes visual Design Mode, GitHub sync and deploys to Vercel. Business is $100 per user per month with $30 of included credits and $2 of free daily credits on login. Usage runs against published per model token rates: output on v0 Mini is $1.20 per million tokens, output on v0 Max Fast is $50.

Lovable calls itself an AI software engineer. Free grants 5 build credits a day, capped at 30 a month. Paid plans add a balance shared across a workspace, and its pricing page prices real prompts: a full landing page with images at 1.70 credits, a button restyle at 0.50.

The call up front: pick on unit of work and meter. On the thing that decides how the result looks, they are the same product, and that is Thanor.

Two different units of work#

The word app is doing a lot of hidden labour in both marketing pages, and unpicking it settles most of the comparison.

Lovable treats the application as the deliverable. Auth, data, a deploy, a thing that is alive and has users. Ask it for a landing page and it will make one, but the product is shaped around the case where the landing page is the front door of something larger.

v0 treats the interface as the deliverable. It returns React, it is fluent in the component conventions of the ecosystem it lives in, and it assumes there is a codebase somewhere that this is going into. The Vercel deploy path is there, and it is a path rather than the point.

That difference shows up on day two, not day one:

• A marketing site with a form. Both are fine. Pick on price.
• A product with accounts and a database. Lovable carries more of it.
• A design refresh of an app you already run. v0 fits your repository.
• Forty small experiments. The meters diverge here more than the features.

Neither is a subset of the other. They overlap in the middle, which is the landing page everybody tests them on, and that overlap is exactly where the comparison teaches you the least. Both produce a credible one in a single message, which tells you nothing except that the demo works.

The instructive test is the fifth revision. That is where the unit of work asserts itself: Lovable is still thinking about the application around the page, and v0 is still thinking about the component tree inside it.

Lovable against v0, attribute by attribute#

Attributes on the left, because the rows are the decision.

The final row is the only one where both columns agree, and it is the row nobody reads before buying.

Everything above it is a genuine choice with a real consequence. Hosted application against interface code. A chat only loop against a direct manipulation surface. Credits granted daily against credits spent at rates that swing by a factor of forty depending on which model you pick.

Settle those with two free accounts and one weekend. Run the same brief through both so the tool is the only variable, and then read both invoices rather than both pricing pages. A pricing page describes the first build. An invoice describes the revisions, which is where the money actually goes.

What each does about consistency#

The two products answer this question differently, and both answers stop at the same place.

Lovable ships design systems on paid plans. The documentation is precise about the mechanism: Lovable reads tokens and components from that source when you release, then runs adherence enforcement during ongoing work, catching raw colours, customised components and other deviations from your design system.

v0 ships Design Mode, on the free plan. Select an element in the generated result and change it by hand rather than describing the change in English. Spacing, size, colour. For that job it is the right tool, and spending model credits to move something 8px is a poor trade.

Now read what each one assumes.

• Lovable's enforcement assumes a token set exists to enforce.
• v0's editing assumes somebody knows which direction to drag.

Deviations and adjustments are both comparative words. They measure against a standard, and neither product supplies the standard, because supplying one would make the tool worse for the agency applying a client brand. That is the correct product decision and both companies have made it deliberately.

So the gap is not an oversight. It is the shape of the market, and it is the same shape in every builder on the shelf.

The brief they are both missing#

Run the same thin brief through both and you get two pages that could be siblings: centred hero, gradient behind it, three feature cards, a soft fade upward on scroll, a weightless sans at one of four sizes.

That is correct behaviour, not a defect. An unspecified brief has to be resolved by something, and the something is a model drawing on the median of published interface work.

The interesting part is how little it takes to break the pattern. Four categories of value, all of them writable in a paragraph each:

1. Colour as values. #0B0B0F and its companions, not dark and modern.
2. A type scale at a stated ratio, resolving to a stated size at a stated breakpoint, so the display size is a decision rather than a default.
3. Motion as a curve and a duration. cubic-bezier(0.22, 1, 0.36, 1) at 620ms reads as considered. The same move at 200ms reads as 2014.
4. A section order, with a reason each section sits where it does instead of inheriting a template's sequence.

Hand that to either tool and both execute it faithfully, because faithful execution is what they are genuinely excellent at. The brief is the variable, not the builder.

The proof is cheap to run. Take one page, generate it twice in the same tool, once with adjectives and once with those four categories filled in, and put the results side by side. Nothing about the software changed between the two.

The verdict#

• Choose Lovable when the deliverable is an application: accounts, data, something that has to stay alive after launch. The shared workspace credit pool is easy to fund for a small team, and the design system enforcement is worth paying for the moment you have decisions to enforce.
• Choose v0 when the deliverable is interface work landing in a codebase you already run, when you want direct manipulation rather than a chat round trip for small changes, and when the Vercel deploy path is already your path.
• Do not choose either on output quality. On a thin brief they converge, and on a precise brief both execute well. A migration between them costs a week and changes nothing a visitor would notice about the page, which is a painful thing to discover on the far side of the week.

What does change it is the specification, and a specification is portable in a way no project file is. Written once, it runs in Lovable, in v0, in Bolt, and in whatever replaces all three. It also outlives the comparison: the meters will move, the plan names will change, and a stated type scale at a stated ratio will still be a stated type scale.

The honest summary: this is a workflow decision wearing the costume of a design decision. Answer the workflow question on your own project, and answer the design question somewhere upstream of both tools.

Browse the Thanor library and read one full specification before your next build.