AI App Builders: What Lovable, Bolt and v0 Give You Before You Hire a Developer

The pitch for these tools is that anyone can build software now. The reality is narrower and still useful: anyone can build the first version of software now, and the first version is where most ideas should have stopped anyway. Used that way — as a fast, cheap way to find out whether something is worth building properly — Lovable, Bolt and v0 are genuinely good. Used as a replacement for ever talking to a developer, they are how a small company ends up with a customer database anyone on the internet can read.

We have built throwaway tools with all three for this site, and we have not shipped any of them to readers. That is a deliberate choice, and the reasons are most of this article.

What each one is actually for

Tool	Builds	Pricing model	Paid entry point	Best at
Lovable	Full-stack web apps, database included	Credits per message; unlimited members	Pro, around $25/mo	A non-developer getting to a working app fastest
Bolt	Full-stack web apps in a browser IDE	Tokens; daily cap on free	Pro, $25/mo	Seeing and editing what the AI is doing
v0	Front-ends and UI, deployable to Vercel	Credits per user	Plus, $30/user/mo	Interfaces, especially if you already use Vercel

Lovable makes the most decisions for you. Describe the app, and it picks the stack, wires up a database, adds sign-in and gives you a URL. It is the one we hand to people who have never seen a terminal, because they can get something working before they have time to be discouraged. The trade is that its choices are its choices; if you later want a different database or a different hosting arrangement, you are exporting the code and continuing somewhere else.

Bolt shows its working. The editor, the file tree and the terminal are all visible, and you can edit the code directly between AI turns. That makes it slower for a complete beginner and much better for anyone who wants to learn what the tool is doing, which is the group most likely to end up with something maintainable. Tokens on paid plans roll over for a month, which matters more than it sounds when you have a quiet fortnight.

v0 is Vercel's, and it is honest about what it is good at: the front-end. Ask for a dashboard, a settings page, a pricing table and it produces clean React that drops into a Next.js project. Ask for a full application with accounts and billing and it will try, but the other two are built for that and it is not. If you already deploy on Vercel, the path from v0 to production is the shortest of the three.

What the pricing actually means

None of these charge per seat in the traditional sense. They charge per attempt. Lovable counts credits per message; Bolt counts tokens, which is roughly the amount of text the model reads and writes; v0 sells credits per user. The listed prices are close — $25, $25, $30 — and they tell you very little about what a month will cost, because the variable is how many attempts your changes take.

A clear request that lands first time costs one unit. A vague request costs one unit plus every clarification. A bug the tool cannot see costs a unit every time you say "still broken". The people who complain about these tools being expensive are usually in a loop of the third kind, and the fix is not a bigger plan; it is stopping, and either rewriting the request from scratch with everything you know, or exporting the code and reading it.

The free tiers are real. Bolt's has a daily token cap that makes it a "build a bit each day" tool; Lovable's gives a small daily grant of credits; v0's is enough to produce a few components. All three are enough to find out whether the idea survives contact with a screen, which is the only thing you should be using the free tier to learn.

Where generated apps go wrong

The code is usually fine. It is the assumptions that are not. A person who asks for "a form where customers submit their details" gets a form that works perfectly when they test it, because they are logged in as the administrator and are entering sensible data. The classes of mistake below are invisible from that seat, and we have seen every one of them in something a builder produced.

• One user can read another's rows. The app has accounts, the database has a user column, and nothing checks that the two match on every query. Lovable's Supabase setup makes this less likely than it was, but "less likely" is not a security policy.
• Keys in the front-end. An API key for a paid service ends up in code the browser downloads, because that was the shortest way to make the feature work. Anyone who views source has your key and your bill.
• Trusting the form. The interface only lets a user pick from three options, so the server never checks the value. Anyone with the browser's developer tools open can send a fourth.
• No thought about ten users at once. Everything works for one person clicking slowly. A hundred people on launch day is a different program.

None of these are exotic. They are the mistakes junior developers make, produced at speed, with nobody in the loop who would recognise them. That is why our threshold is simple: the day the app holds anyone else's data or takes anyone's money, a developer reads it. A day of review is cheap. We went through the equivalent decision for sign-in specifically in authentication: build or buy, and the answer there is even more firmly "buy".

A way to use them that works

1. Build the ugliest version that answers the question. The question is "would anyone use this", not "is this good". Two screens, no styling, fake data if you must.
2. Put it in front of five people this week. Real people, real task, watch them. This is what the tools are for, and it is the step that would have cost a month and a developer two years ago.
3. Decide, honestly. Most prototypes should stop here. If it stops, you have spent a free tier and an afternoon.
4. If it continues, export the code before you add anything else. Put it in a repository. From here, every change either goes through someone who can read it or gets reviewed by one.
5. Keep using the builder for the front-end. This is where they stay useful long after the prototype stage. Interfaces are cheap to regenerate and low-risk to get wrong.

What we would pick

• You have never built anything and want to see an idea on a screen: Lovable, free tier, this afternoon.
• You know a little code and want to learn as you go: Bolt. Watch what it does, edit between turns, and you will come out able to maintain the result.
• You need interfaces for an app that already exists: v0, especially on Vercel.
• The prototype has users: whichever tool you used, plus a developer for a day. We compared what the agent-style coding tools are like to work alongside in a week with an AI coding agent; the difference is that those assume a developer is present, and these assume one is not.