How to use Lovable, and when to take the code and go

Lovable is the tool most people mean when they say vibe coding: type what you want, watch a working web app assemble itself, share a link the same afternoon. No editor, no terminal, no build step. It is genuinely the fastest way for a non-coder to get from idea to something clickable, and that part of the pitch survives contact with reality. The part that does not: treating the output as finished. Lovable is step one. The builders getting real value use it as a disposable prototyping layer and leave on time; the ones getting burned run production apps on it, pay per message while it debugs its own regressions, and in a few hundred documented cases shipped databases strangers could read. This guide is how to be the first kind.

What it is, and what you get

You describe an app in chat. Lovable’s agent plans, writes, and edits a real codebase: TanStack Start with server rendering on new projects (React and Vite on older ones), Tailwind for styling, and a backend wired through Supabase or Lovable’s own Cloud. It deploys to a lovable.app subdomain when you hit publish, syncs two ways with GitHub, and since 2026 ships with subagents, Stripe payments, scheduled jobs, and an MCP server. Web apps only: it will make you a mobile-friendly site, not a native app, and it cannot start from an existing codebase.

Four ways to touch a project, and they cost different money:

• Build mode is the agent. It plans, edits many files, checks its work. This is the default and the meter.
• Plan mode talks through the approach without touching code, at a flat one credit per message.
• The preview toolbar does tiny edits directly on the running app; inline text changes are free up to 100 a day.
• Code mode is a real editor on the underlying files, on paid plans. Free to type in, and the escape hatch the chat-only crowd forgets exists.

The workflow that survives

The pattern below is assembled from Lovable’s own best-practices docs and the users deep enough to have opinions worth copying.

1. Plan before you build, most of the time. Heavy users report living in plan and chat mode for well over half their messages, and Lovable’s docs agree. Talking is one credit; letting the agent guess wrong across six files is not.
2. Build the skeleton in the right order. The clearest advice on r/lovable comes from a builder about 50 projects deep: auth first, then security, then the database schema, then payments, and the pretty UI last. “If you get too far down scope, you can’t go back and rebuild core.”
3. Write the knowledge file. Every project has one, sent with every prompt. Stack facts, conventions, and standing rules (“do not edit the shared layout”) go here. It is the same habit as Claude Code’s CLAUDE.md and it does the same job: it stops the agent re-making the same mistake at your expense.
4. Scope one change per message. The death spiral starts when a vague prompt touches five things and breaks two. Small asks, review the result, next ask. One builder documented breaking three unrelated features by adding one, with no idea why, and that story is the normal failure mode, not the exception.
5. Prototype in parallel, throw most of it away. Spinning up several cheap variants of an idea and keeping one is the use case where everyone agrees the tool pays: a startup CTO on Hacker News put it plainly, even if the code were deleted afterward, validating assumptions alone saves “a ton of man hours per feature.”

The money: a meter that bills by difficulty, and keeps running

Lovable’s pricing looks simple and is not. Pro starts at $25 a month for 100 credits, the free tier gives 5 build credits a day capped at 30 a month, and top-ups run $15 per 50 credits. The part that decides your bill is what a credit buys. Since the Agent launch, work is priced by complexity: restyling a button around half a credit, wiring auth about 1.2, a landing page with images near 2. A stopped or failed run still charges for the work done so far. And since June 2026 there is one pooled balance for everything: agent work, your app’s database and hosting usage, and the AI calls your deployed app makes all draw from the same tank.

Two consequences follow, and both show up in the receipts. First, debugging is billable, including debugging of the agent’s own mistakes. The canonical complaint is a builder who spent 400 credits on a first simple app “because lovable kept breaking everything,” and the pattern fills a 140-point Hacker News thread on whether charging users to fix the tool’s own regressions is a viable business model. When the 2.0 repricing landed, one $200-a-month customer summarized the mood: charged “for every single message… especially since Lovable… breaks things all the time.” Second, because your deployed app’s backend usage draws from the same pool, a live app stops responding to new requests when the credits hit zero. Read that twice if you have users: your subscription lapsing takes their app down with it.

The defensive habits are the workflow above plus arithmetic: plan mode for thinking, one scoped change per build message, free preview-toolbar edits for copy tweaks, code mode for anything you can type yourself, and a look at the credit estimate before big runs. Budget for the app you will debug; describing it is the cheap part.

Security: three incidents, one lesson

This is the section the fan content skips, and it is the one that matters if your app touches other people’s data.

In early 2025 a researcher scanned 1,645 Lovable-built projects and found 170 of them, about one in ten, leaking data through missing or broken Supabase row-level security: names, emails, home addresses, API keys, personal debt amounts. He could write as well as read, at one point marking an order as paid without paying. That became CVE-2025-48757. In February 2026, a Lovable-hosted exam platform exposed 18,697 user records; the researcher described one flaw as “a classic logic inversion that a human security reviewer would catch in seconds.” In April 2026 the exposure was the platform itself: a researcher pulled other users’ source code, secrets, and chat histories through Lovable’s own API before it was fixed.

Lovable’s response has been real but bounded: a free security scan runs before every publish, a deeper agentic scan is on demand, and the docs now warn you to review generated database policies. The bound is in the company’s own words, from its CISO: acting on the findings “is at the discretion of the user.” The scanner also checks that access rules exist, not that they match your app’s logic, and logic is where the exam app failed. So the working rules are short. Run the scan and act on every finding before anything real touches the app. Treat database policies as your responsibility, not the agent’s; if you cannot read them, do not store anything you would mind leaking. And do not collect sensitive data, health, finances, minors, in a vibe-coded app at all. The convenience you are buying does not cover that risk, and after three public incidents, “I did not know” no longer covers it either.

The off-ramp: GitHub, then Cursor, before complexity bites

The most-upvoted advice post in Lovable’s own subreddit is titled stop using Lovable for everything, and its argument matches what shipped builders describe: Lovable for the UI and the working prototype, then export and finish like an engineer. The mechanics are good. You own the code, the GitHub sync is genuinely two-way, and the repo runs anywhere. From there, Cursor for in-loop editing or Claude Code for delegated tasks picks up the last 20% that Lovable fights you on. One builder’s arc is the template: 160 hours from first Lovable prompt to reviewing code line by line in Cursor, and 7,500 waitlist signups the day she shipped.

Three gotchas on the way out, all learned expensively by someone else:

• Never rewrite git history against the sync. A force-push broke one builder’s integration permanently. Treat the Lovable-synced branch as append-only.
• Choose Supabase over Lovable Cloud if you might ever leave. Your Supabase project is your account and keeps working without Lovable. Cloud cannot be disconnected from a project and has no documented migration out. Convenient in week one, a wall in month six.
• Know what cancellation does. Published sites can go offline after the billing period ends, and unused credits freeze. Export the repo and move hosting before you cancel.

Where it stops being worth it

The Primer rule is to know your off-ramp before the bill, or the breach, surprises you.

• Production apps holding real user data, unless you can read and verify the security policies yourself or pay someone who can. One in ten scanned apps says the default is not safe.
• Anything where design is the product. Even fans concede the output converges on the same tasteful-template look; differentiated design still takes a designer, or v0 plus your own taste.
• Complex logic and big apps. The generated architecture favors speed over structure, and past a moderate size, edits start breaking neighbors. That is your graduation notice; no prompt will fix it.
• Native mobile, or building onto an existing codebase. It does neither.
• You can already drive an editor. If Cursor is comfortable, Lovable’s value narrows to the first afternoon; you will hit its ceiling in a weekend. The tools we currently stand behind are on the Palette.

Lovable earns its keep as the fastest idea-to-demo machine available: the prototype that wins an argument, the MVP shell that gets you feedback, the UI you did not have to design from a blank file. It stops earning it the moment you mistake the demo for the product, because everything after that moment, the per-message debugging, the credit-metered hosting, the security policies nobody read, bills against you. Build the argument in Lovable. Ship the business from a repo you own. The builders who keep it in that lane swear by it, and the ones who did not are the receipts in this guide.