Back to All Cheatsheet Libraries cheatsheets

Lovable

The AI app builder that writes real code — prompting technique, scoping discipline, the credit model, and the security checks to run before you publish.

Describe an app, get real code

Lovable generates full-stack web apps from natural language — frontend, backend, database, auth, and integrations — and it produces actual code you own, syncable to GitHub or GitLab, rather than a locked-in no-code artefact.

The thing that decides whether you get a usable product or a mess is how you prompt and how you scope. The docs are unusually direct about this: "Small prompts compound. Big prompts collapse into changes you did not ask for and cannot untangle." That single sentence is most of the skill.

Concept What it is Notes
Plan modeProject-aware planning. Inspects files, database, and logs, asks clarifying questions, and proposes a plan you can edit before any code is written.Use for anything bigger than a tweak. Flat 1 credit per message.
Build modeExecutes — generates and edits code.Variable cost by complexity, roughly 0.5–2 credits per message.
Select elementsClick a component in the preview, then describe the change.You give spatial context by pointing, so the prompt gets shorter. Consumes credits as normal chat.
Inline text editingEdit copy directly in the preview.100 free edits per user per day before credits apply — use this for all copy changes.
Version historyEvery change creates a version automatically. No save button.The docs put it well: "Version history is what makes bold prompting safe."
Knowledge fileA one-page project brief Lovable reads as standing context.The highest-leverage setup step. See the Building tab.
CloudBuilt-in backend — database, storage, edge functions, realtime.Billed by usage against a monthly grant, separately from build credits.
Git syncTwo-way sync with GitHub or GitLab.Your escape hatch. Connect it early — it's how the project stops being trapped in one tool.
PublishDeploy to a live URL.Run the security scan first.
What it's genuinely good and bad at
  • Good: going from nothing to a working, clickable prototype fast; CRUD apps, internal tools, landing pages, dashboards; exploring a product idea before committing engineering time.
  • Good: the output is real code in a real repo — you can walk away with it, which is not true of most no-code tools.
  • Harder: large existing codebases, unusual architectures, and anything where the precise implementation matters more than the visible behaviour.
  • Harder: long unattended runs. It rewards short verified steps and punishes big vague asks.
  • Treat it as a very fast junior who never pushes back — the scoping and the review are your job.

The four-phase framework

Lovable's own documented approach. It's worth following literally, because most bad output traces back to skipping phase one.

1

Lay the foundation

Before prompting, answer four questions: what is it, who's it for, why would they use it, and what's the key action? Vagueness here produces generic output no amount of iteration fixes.

2

Think in systems

Ask for modular components, not whole pages. Use atomic UI vocabulary — "buttons, cards, modals" — rather than abstract requests like "a user interface".

Use real content from day one. Placeholder text hides design problems until they're expensive.

3

Build with precision

Name the location, the exact behaviour, and the boundaries. Guardrails like "only change the orders page" or "keep the existing styling" are what stop collateral edits.

The docs are blunt about this: "Naming what you don't want is as useful as naming what you do."

4

Iterate and ship

One change per prompt, verify in the preview, then move on. Bookmark a version after every working feature so you always have a known-good state to fall back to.

Techniques worth using
  • Ask it to ask you. End a prompt with: "Ask me any questions you need in order to fully understand what I want from this feature and how I envision it." Cheap, and it surfaces the assumptions before they're baked into code.
  • Describe the feel, not just the layout. Style words — "minimal", "expressive", "cinematic", "playful", "premium", "developer-focused" — move typography, spacing, shadow, and colour together and coherently.
  • Point instead of describing. Select-elements gives spatial context, so "make this the primary brand colour" beats "the third button in the header".
  • Reuse your design language. Consistent vocabulary across prompts produces a consistent product.
  • Name the role. On any shared screen, say which user type a change applies to, or it'll apply to everyone.
  • Add visuals by URL. Reference images directly rather than describing an aesthetic in prose.

Weak vs strong, from the docs

# Weak — no audience, no action, no aesthetic Build a website for a budgeting app # Strong — audience, CTA, and visual direction all specified Build a one-page site for a budgeting app targeted at Gen Z freelancers. The main CTA should be "Start Saving Smarter." Focus on a bold, expressive aesthetic with large text and punchy colors. # Scoped edit — location, behaviour, and an explicit boundary On the orders page only, add a status filter above the table with options All / Pending / Shipped. Keep the existing table styling and do not change any other page. # Clarify before building I want a booking flow for a yoga studio. Ask me any questions you need in order to fully understand what I want from this feature and how I envision it, before writing any code.

Set up a knowledge file first

A one-page brief Lovable reads as standing context on every prompt. It's the difference between re-explaining your product every session and having it already understood.

You don't have to write it cold — ask Lovable: "Generate a knowledge file for this project based on what we've built so far." then correct it.

# What belongs in it - Product definition and target audience - Main user journeys, concretely e.g. "a client books a session in under a minute" - Key features, and how behaviour differs per role - Design guidance: tone and visual direction - Common issues Lovable gets wrong on this project # That last section is the one people skip and the one that pays most — # every recurring correction you make belongs in it permanently.
When to add the backend
  • Add it when information needs to persist — surviving a refresh, or shared between users. Not before.
  • Build the frontend first with sample data, finalise the screens and flows, then connect the database. It iterates faster and keeps early sessions about the product rather than the data model.
  • Verify the backend the reliable way: open the app in two browser tabs, create a record in one, refresh the other. If it appears, it's real.
  • After adding authentication, always test with two different users to confirm one user's private data is invisible to the other. This is the single most commonly skipped check.
Before you publish
  • Run the security scan and fix anything flagged critical. The docs say to do this before your first publish, and it's the right advice — generated apps routinely ship with over-permissive data access.
  • Re-test the two-user check on the published URL, not just the preview.
  • Check what's exposed client-side. Anything in frontend code is public, API keys included.
  • Connect Git sync before launch so you have the code independently of the platform.
Getting out of an error loop
  • When a build error appears, a Try to fix button scans the logs and attempts a repair. You get 10 free fixes shared across all workspaces, each replenishing 24 hours after use.
  • Use Try to fix once or twice — then stop. If it persists, switch to Plan mode to find the root cause.
  • Do not re-send the same prompt hoping for a different result. Per the docs, "repeated blind fixes tend to pile up code that hides the real problem."
  • If the app runs without errors but behaves wrongly, that's a Plan-mode problem, not a Try-to-fix problem.
  • When it's genuinely tangled, revert to a bookmarked version and take a smaller step. Cheaper than debugging accumulated damage.
Version history and reverting
  • Every change creates a version automatically — history is always complete, with no save step.
  • You can rewrite one of your own text messages and choose Revert and resend to roll back to the state before it and try a different prompt.
  • The critical caveat: reverting restores your code, not your database data. A revert will not undo records created, altered, or deleted in the meantime.
  • Bookmark a version after every working feature. That's what makes aggressive prompting safe.

Three things consume credits, not one

Worth understanding before you're surprised by a bill. Plans are priced by credits, not by projects or seats.

Type What consumes it Notes
Build usageMessages that plan, generate, edit, or update the app.Plan mode is a flat 1 credit. Build mode varies with complexity — roughly 0.5 for "make the button gray" up to 2 for "build a landing page with images".
Cloud usageHosting and the built-in backend: database, storage, bandwidth, edge functions, realtime.Accrues continuously once published — this is the one that surprises people, because it isn't tied to your activity.
AI Gateway usageAI calls your deployed app makes to models.Charged per token and varies by model. If your app has AI features, its users spend your credits.
Rollover and expiry — the rules that actually matter
  • General monthly plan credits roll over while your subscription stays active, expiring 2 months after issue (monthly plans) or 1 month after the annual cycle ends.
  • Usage-specific grants do not roll over. Daily build credits expire at end of day; monthly Cloud and AI grants expire at the end of the period.
  • Top-up credits are valid 12 months from purchase.
  • Spending order is automatic and sensible: usage-specific grants first, then whichever general credits are closest to expiry. You don't need to manage this.
  • Daily build credits are use-it-or-lose-it — on a daily allowance, a light day is a wasted day.
Not wasting them
  • Use inline text editing for copy. 100 free edits per user per day. Prompting "change this heading" spends a credit for something that's free.
  • Plan mode costs a flat 1 credit and often replaces several failed Build attempts. Cheap insurance on anything non-trivial.
  • Check what a message cost via the three-dot menu on the response — the fastest way to learn which asks are expensive.
  • One change per prompt. A failed big prompt costs more than the two small ones that would have worked.
  • Review Usage details to find which projects are consuming most, and set member credit limits on teams.
  • Enable auto top-up if a service pause would be disruptive (Pro/Business).
  • Unpublish or clean up abandoned projects — Cloud usage keeps accruing on anything still deployed.

Per-plan allowances and top-up prices change, so check lovable.dev/pricing and the credits documentation for current numbers rather than trusting any figure quoted here. The model above — three usage types, grants before general credits, daily credits expiring nightly — is the part that stays stable.

Gotchas

Reverting does not restore your data
  • Version history restores code. Records created, modified, or deleted since that version stay as they are.
  • A revert after a bad migration can leave your schema and your data disagreeing.
  • Export or back up anything important before a destructive database change. There is no undo for data.
  • Test schema changes on sample data first, not on the records you care about.
Security is your responsibility, not the generator's
  • Generated apps ship with over-permissive data access more often than you'd hope. Run the security scan before publishing and fix critical findings.
  • Always test with two separate user accounts. "It works when I'm logged in" tells you nothing about isolation between users.
  • Anything in frontend code is public. API keys, secrets, and admin endpoints belong server-side.
  • Lovable holds SOC 2 Type II and ISO 27001:2022 certifications, and offers 2FA, SSO, SCIM, audit logs, and sensitive-data scanning — but that's the platform's posture, not your app's. Your generated app's security is on you.
Other things worth knowing
  • Big prompts are the main failure mode. Ask for five things and you'll get four plus a change you didn't want, tangled together and hard to unpick.
  • Repeatedly hitting Try to fix makes things worse, not better — it accumulates code that obscures the real cause.
  • Cloud usage accrues on published apps whether or not you're working on them. Abandoned deployments quietly cost money.
  • If your app calls AI models, your users' activity spends your credits. Rate-limit anything public.
  • Connect Git sync early. It's the difference between a project you own and one you can only edit in one place.
  • Placeholder content hides design problems. Use real copy from the first prompt.
  • Several record-changing prompts in flight at once produce unpredictable results. One change, verify, next.
  • The product moves fast — features and pricing shift. Check the changelog rather than assuming.

Tips

Plan mode before anything non-trivial

Flat 1 credit, project-aware, and it asks clarifying questions before writing code. It routinely replaces several expensive failed Build attempts.

Bookmark every working state

A named version after each finished feature turns a bad prompt from a debugging session into a two-click rollback.

Inline editing for copy is free

100 edits per user per day at no credit cost. Never spend a build credit on changing a heading.

Point, don't describe

Select-elements supplies the spatial context, so your prompt only has to carry the change. Shorter prompts, fewer misfires.

Put recurring corrections in the knowledge file

Every time you fix the same mistake twice, that's a line for the "common issues Lovable gets wrong" section. It stops repeating.

Sync to Git on day one

Real code in your own repo means you can bring in a developer, run your own CI, or leave entirely. Do it before you're invested.

Resources

Lovable documentation Workspace, projects, features, integrations, prompting, and enterprise. docs.lovable.dev How to build a real product The best page in their docs — scoping, knowledge files, backend timing, security. docs.lovable.dev Credits & usage The authoritative, current breakdown of what costs what. docs.lovable.dev Version history Revert, restore, and revert-and-resend — including the data caveat. docs.lovable.dev Debug & improve your app What to do when Try-to-fix isn't working — the error-loop escape route. docs.lovable.dev Changelog The product moves quickly — check here before trusting older guidance. docs.lovable.dev Git & GitHub Where your synced project lives, and how to work with it outside Lovable. build.ty1er.com Claude Code The natural next step once a synced project outgrows in-browser prompting. build.ty1er.com

Compiled from Lovable's official documentation, August 2026. Credit allowances, plan tiers, and features change frequently — verify against docs.lovable.dev and the pricing page. The platform's SOC 2 and ISO certifications describe Lovable's own posture, not the security of the app it generates for you: run the scan, and test with two accounts, before you publish.