Lovable vs v0: app, or a screen in the repo?

Short answer: use Lovable when you want a prompt to become a running app: pages, auth, a database, and a deploy, and you are willing to review what it generated. Use v0 when you want interface code you can drop into a React codebase you already have, usually on Vercel, and you will keep owning the components. Lovable is closer to “ship the product”. v0 is closer to “ship the UI”. They meet when a founder types a sentence and expects a company.

This is for a founder, a product designer who is also shipping, or an engineer who is tired of scaffolding the same login. If you already have a repo and a design system, you are not behind. The mistake is letting a generated app become the only copy of the product, with no one who can read the diff.

Both sit on Unloc under coding agents: Lovable and v0. If the argument is really “which assistant writes inside the editor I already use”, read Cursor vs GitHub Copilot and Claude vs Cursor. Those are about the editor and the chat. This one is about generating the thing a user can click.

Quick verdict

If you cannot say whether you need a product or a component, stop prompting. Write the job in one sentence. “A page a customer can sign in to” is an app. “The settings form in the app we already have” is a component. The tools will happily do the wrong one.

What Lovable is for

Lovable takes a prompt and builds a full-stack app: the screens, the auth, a database, and a way to deploy. You iterate in chat. You can open the code. The point of the product is that a person who is not setting up a framework from scratch can get to a URL that does something. That is a real job. Studios and founders use it for the first version of a tool, an internal app, or the prototype that has to take a real signup rather than a slide.

The win is the stack you did not have to assemble. Login, a table, a form that writes a row, a deploy. The loss is ownership. A generated app is still code. If nobody on the team can read a route, a query, and a migration, you do not have a product. You have a demo that will break on the first unusual request. Lovable is a good way to start. It is a bad place to leave the only copy of the business logic if the person who prompted it has moved on.

Treat the first generation as a draft, the way you would treat a first layout. Click every path. Try the empty state. Try a second user. Read the diff before you invite a customer. The tool will invent reasonable names and also invent structure you did not ask for. Delete what you do not need in the first week, while you still remember why it appeared.

Lovable is not a design system and it is not a substitute for a sentence about who the app is for. A prompt that says “build me a CRM” will build a picture of a CRM. A prompt that says who signs in, what they create, and what “done” looks like will build something you can test. Write that down before you type it into the chat. The chat is not the brief. The brief is the brief.

What v0 is for

v0 is Vercel’s UI agent. You describe an interface and it generates React, commonly with the component style a lot of product teams already use. You iterate on the screen, then you take the code into a project. The deploy story is Vercel’s, because that is the company. The point is not “an app appeared”. The point is “this screen is now code I can edit”.

The win is speed on the interface without leaving the stack you ship. A settings page, an empty state, a pricing layout, a dashboard frame. A designer who can read JSX, or an engineer who does not want to hand-build another card, can get a starting point that matches the way the rest of the app looks. The loss is everything that is not the interface. Auth, the database, the permission check, the email, the job that runs at night. v0 will not quietly become your backend because the button looks finished.

v0 fits a repo that already exists. You are adding a surface, not founding the company inside the generator. If the repo does not exist yet, you can still start there, and you should notice that you are now doing the Lovable job with more assembly. That can be the right trade when you know you want the code in your own project from the first hour.

Review the component the way you would review a colleague’s pull request. Names, states, the loading and the error, the bit that is hardcoded and should be a prop. A generated screen that only works with the sample data is a picture. Wire it to the real data before you call it done. And do not paste a second copy of the button you already have in the design system. If the app has a button, the generation should use it.

Side-by-side

Neither tool decides the offer, the permission model, or what happens when the happy path fails. You still write those down. A generated login is not a security review. A generated table is not a data model. If the product handles someone else’s information, a person who understands that information has to read the code before a stranger does.

Pricing snapshot

Both meter generation, and both have a paid step when you keep going. The numbers move, and the surprise is usually the limit on messages, projects, or seats, not the first demo. Read the current plan on Lovable and on v0 the week you buy. We are not quoting a price here.

• Lovable’s bill follows how much you generate and how you host the app that came out. A weekend prototype and a product with real users are not the same plan. Check before you invite the team.
• v0’s bill follows generation as well, and the hosting conversation is Vercel’s if that is where the project deploys. A component you pasted into an existing project is not the same cost as a new project with its own usage.
• The costly mistake is paying for both and keeping two versions of the same screen, one in a generated app and one in the real repo.

Who Lovable is best for

Lovable is for a person who needs a working slice this week and does not already have the app. A founder testing whether anyone will sign up. A studio building a small internal tool. A hackathon that has to demo a real click, not a slide of a click. It is also for an engineer who wants the boring shell generated so they can spend the day on the part that is actually specific.

It works when someone will still read the code. The prompt gets you to a URL. The review gets you to something you can leave with a customer. If the team’s plan is “we will hire an engineer later to understand it”, write that down and keep the scope small enough that later is possible. A generated system with twelve features is not a starter. It is a rewrite.

Not ideal if

• The app already exists and you only need a screen. You will create a second product by accident.
• Nobody can review a database query or a route. You cannot ship other people’s data on hope.
• The brand and the components are already a system in a repo. Starting over in a generator throws that away.
• You need a careful, slow interface in a regulated flow. Generate the draft. Do not generate the approval.

Who v0 is best for

v0 is for teams who already ship React and want the interface to move faster. A new page in the product. A marketing section that should be code, not a picture. An empty state, a dialog, a table that matches the rest of the app. It fits an engineer, or a designer who is comfortable taking JSX and adjusting it, with someone else reviewing the result.

It is the better tool when the design system is in the repo and the job is to extend it, not to invent a parallel app. Say so in the prompt. Point at the components you already have. Reject the generation that redraws the button. The speed is useless if you now maintain two buttons.

Not ideal if

• You need auth, a database, and a deploy as the whole job, and you do not want to assemble them. That is the other tool.
• The person prompting cannot read the output and nobody else will. You will paste a component you cannot change on Thursday.
• The product is not a web UI. A generated React page will not become a native app or a back-office process.
• You wanted a strategy. A screen is not a decision about who the product is for.

Workflows that hold up

The weekend MVP

Write five lines before you prompt: who signs in, what they create, what they see afterwards, what is out of scope, and what “we will know on Monday” means. Open Lovable. Generate the smallest version of that. Click it as a stranger. Then read the code for the one path you will actually show. Delete the settings page you did not ask for. Deploy that, and stop. A second feature can wait until a person who is not you has used the first one.

The screen in the real app

Open v0 against the UI you already have in your head, and be specific: the type, the spacing you already use, the components that must not be reinvented. Generate the screen. Bring it into the repo as a change you can diff. Wire it to the real data. Do not leave the sample names in. If the generation fights the design system, fix the prompt or fix the component. Do not merge both.

The handoff

A generated app needs a README a person can follow: how to run it, where the data lives, what is fake. Lovable’s project should be in a repo the team controls, not only inside the product that generated it. v0’s output should be a pull request, not a zip file in a chat. If you cannot explain the path from prompt to production in a paragraph, you do not have a handoff. You have a demo.

When the generation is wrong

Do not prompt “make it better” five times. Say what is wrong: the empty state, the extra field, the route that should not exist. Small corrections beat a fresh app. If the structure is wrong, start again from the brief rather than stacking patches on a plan you do not want. Keep the brief in the repo. The chat will not remember it for you next month.

Switching, without pretending it is an export

Lovable to v0 is not a format conversion. If you started in Lovable and the app is now real, you usually stay in that repo and edit it like any other codebase, with Cursor or whatever editor you trust. You do not re-generate the same app in v0 to “make it professional”. You take the screens that are wrong and rebuild those screens, in the repo, on purpose.

v0 to Lovable is the opposite mistake when the component was never the product. If you have a folder of generated pages and no auth, and what you needed was an MVP, you can start again in Lovable from the brief. Do not paste the pages in and hope the data appears. Write the data model. Then generate the smallest app that matches it.

Using both on one product is normal if the roles stay clear. Lovable, or the repo it produced, is the app. v0 is how you try a screen before it lands in that repo. The moment you have two deploys and two databases, you have two products. Pick one URL.

Questions people actually search

Is Lovable better than v0?

For a first app with accounts and data, often yes. For UI inside a codebase you already ship, no. They are different jobs. Paying for both “to see” is fine for an afternoon. Keeping both as the source of truth is how the product forks.

Can v0 build a full app?

It can generate a lot of interface, and you can assemble an app around it. That assembly is the work. If you wanted the assembly done, you are describing Lovable, or you are describing an engineer. Do not expect the UI agent to invent your permission model because the dashboard looked finished.

Can Lovable replace an engineer?

It can replace the first day of scaffolding. It cannot replace someone who will read the diff, name the data, and be accountable when it breaks. If you are the founder and you can read the code, you may be that person for a while. If you cannot, budget for the person before the users arrive, not after the first incident.

Which one should a designer open?

Open Lovable if the job is a clickable product and you will pair with someone who can read the result. Open v0 if you are already comfortable in the repo and the job is a screen. If you are exploring a flow and nobody is shipping it, a design file is still the cheaper place to be wrong. These tools are for when the artefact is code.

Where do Cursor and Claude fit?

Claude is the chat for the brief and the plan. Cursor is the editor for the repo. Claude vs Cursor is that split. Use them on the code Lovable or v0 produced. Do not open a third generator to fix a function you could edit.

How to decide this week

Write the artefact down. An app a stranger can sign in to, or a component in the app you have. If it is the app, open Lovable, keep the scope to one path, and put the result in a repo you control. If it is the component, open v0, generate against the system you already have, and merge it as a diff. If you need both, generate the app once, then use the UI agent only for screens inside that repo.

Lovable gets you to a URL that does the job. v0 gets you to code that matches a codebase. Neither one is the brief, and neither one is the review. Use the one that matches the artefact, and do not leave the only copy of the product inside a chat.

Lovable and v0 are on coding agents. Organic listings are not ranked by who paid. This piece does not use affiliate links. The links go to the products and to the listings already on Unloc.