Lovable vs Claude Code for paid work

Lovable will take you from nothing to a working demo faster than any tool I've used. Claude Code will take you from a working demo to a paid invoice. The mistake — the one I see constantly — is thinking those are the same trip.

The demo machine

Lovable is a browser tool. You type what you want, and it assembles a React app in front of you: components, styling, a hosted preview link you can send to anyone. No terminal, no setup, no git. For getting from zero to "look at this" it is genuinely excellent, and I'm not going to pretend otherwise — I've used it, and it does what it promises.

For client work, that first stretch matters. A prospect who can click through a rough version of their site on the first call is a prospect who understands what they're buying. I've watched people close projects off the back of a Lovable preview built during the meeting. As a sales aid, it earns its place.

Here's what that first stretch actually covers, though: layout, placeholder copy, a colour scheme, some hover states. Call it the first 80% of the visible surface — which sounds like most of the work and is actually the cheap part. Nobody has ever paid me for the first 80%. The invoice lives entirely in the remaining 20%.

The delivery machine

Claude Code runs in your terminal, inside a real repository. That sentence sounds less impressive than a live browser preview, and it's exactly why it wins for paid work.

A repo means git history — every change recorded, every mistake reversible. It means the files are yours: your hosting, your domain setup, your deployment pipeline, no platform sitting between you and the client's website. And it means the AI can do things a browser sandbox can't: run your build, read the errors, fix them, run it again. Edit fourteen files in one pass because the client renamed their main service. Wire a form to a real database and test the failure states.

The way I direct it is a written brief — a master prompt with the stack, the design rules, and a QC checklist the build must pass. The last line of every brief is some version of this:

# Definition of done — run until all three pass clean:
npx tsc --noEmit
npm run lint
npm run build

"Done" stops being a feeling and becomes an exit code. That's the difference between a tool that generates code and a process that delivers projects.

The brief is also where taste lives. Mine carries a design-rules section and a "do not" list that has grown one line per project for a year:

## 5. DO NOT
- No gradients, no glassmorphism, no stock icon confetti.
- No placeholder copy in any committed file.
- No new dependency without asking me first.
- Forms: never ship without a visible failure state.

You can't feed a document like that to a browser prototyper and have it hold across sessions. In a repo, it's just a file — the AI reads it at the start of every session, and project #9 inherits everything projects #1 through #8 taught me. That compounding is the real product; the code is almost a by-product.

Where Lovable stops

Every tool has a ceiling. The problem is that you find it mid-project, with a deadline, with money already agreed. So it's worth knowing exactly where this one is.

The change request, three weeks later. The client emails: the pricing changed, the photo needs swapping, add a field to the form. Trivial work — if you control the repo. Inside a platform, you're re-prompting a UI and hoping it doesn't reshuffle things that were already approved. Version one of anything is the easy part; paid work is mostly living with versions two through nine.

The integration that isn't in the happy path. A local payment provider. A booking system with a terrible API. DNS records on a registrar the client's cousin set up in 2019. Real projects are full of these, and they get solved in a terminal, not a prompt box.

The export trap. Yes, you can export the code and leave. But the moment you do, you're maintaining a codebase you didn't structure, without the tool that made writing it fast. I've inherited two of these projects from other freelancers. Both times, rebuilding from my own master prompt was faster than adopting the export.

The invisible 20%. Titles and meta descriptions per page. The Open Graph image that shows up when the client shares their own site on WhatsApp. Redirects from the old URLs so their Google ranking survives the relaunch. A Lighthouse score that doesn't embarrass anyone. None of this appears in a preview window, all of it is what a business is actually buying, and a prototyping tool has no opinion about any of it.

None of this makes Lovable bad. It makes it a prototyping tool being sold as a delivery tool. The question is never "which tool is better?" — it's "whose ceiling is above your invoice?"

What about Cursor

The other name that always comes up. Cursor is an AI-first code editor, and it's very good — if you already live in an editor. Its whole model assumes you're reading diffs, jumping between files, reviewing code line by line. For a working engineer, that's a feature.

If you're coming from zero, it's friction. You'd be learning an IDE and a codebase's anatomy at the same time as learning to direct AI, and the editor's whole interface quietly pressures you to care about individual lines of code when your actual job is to care about the shipped result. Claude Code's model — you write the brief, it does the typing, you judge the result in the browser — matches the job you're actually doing for a client, which is directing, not editing. I know engineers who are faster in Cursor than I am in anything. I also know that none of my students needed it to bill their first project.

What I actually do

My studio's process, unchanged for every client website since 2025: master prompt into Claude Code, build in a repo, run the QC checklist, deploy to Vercel, send the invoice. A typical marketing site is a few sessions of directed building plus one QC pass — the terminal does the typing, the checklist does the arguing, and I do the judging. Lovable appears occasionally in one place — a throwaway sketch during a discovery call, to get a "yes, like that" out of a client faster than words can. Nothing from that sketch ships. The rule that falls out of all this is short enough to remember:

Prototype in whatever makes you fast. Deliver from a repo you own.

Because the client isn't paying for the demo. Anyone can produce a demo now — that's precisely what the demo machines have made free. They're paying for the part after the demo: the changes, the edge cases, the boring reliability of a thing that stays shipped. Pick the tool that's built for the part they're paying for.