Lovable turns plain English into a full React + Tailwind app, and Lovable Cloud wires a native Supabase backend behind it (Postgres, auth, storage, RLS, real-time). The quality of what you get out is decided almost entirely by the quality of what you put in. A one-line prompt gets a demo; a structured prompt gets an app.
This guide gives you a reusable formula, the workflow that keeps builds stable, and 10 real prompts you can paste today. For more packs, see our roundup of the best Lovable prompts, grab ready-made Lovable prompt templates, or keep the Lovable prompt cheat sheet open while you build.
The 8-part app prompt
Most weak prompts are missing structure, not detail. Describe an app the way a product spec would, in eight parts. You do not need all eight in every follow-up prompt, but your first full-app prompt should cover them.
- Goal / outcome — what the app does and who it is for, in one sentence.
- Users & roles — the personas and what each is allowed to do.
- Data model — the entities and their fields.
- Screens / pages — the pages and what appears on each.
- Workflows — the key flows a user completes end to end.
- Rules / permissions — who can see and do what.
- Design — style, tone, and any brand constraints.
- Acceptance criteria — how you will know it works.
Here is the formula filled in for a real app, a Client Portal for a small agency:
Build a Client Portal web app.
GOAL: A portal where an agency shares project updates, files, and invoices with its clients, so clients can check status without emailing.
USERS & ROLES:
- Admin (agency staff): manages clients, projects, files, invoices.
- Client: views only their own projects, files, and invoices.
DATA MODEL:
- Client: id, name, company, email, created_at
- Project: id, client_id, title, status (planning|in_progress|review|done), due_date
- Update: id, project_id, body, posted_at
- File: id, project_id, filename, url, uploaded_at
- Invoice: id, client_id, number, amount, status (draft|sent|paid), due_date
SCREENS:
- Login
- Admin dashboard: list of clients + projects with status
- Project detail: updates timeline, file list, linked invoices
- Client home: their projects and latest updates
- Invoices page: table with status badges
WORKFLOWS:
- Admin creates a client, then a project, posts updates, uploads files, sends an invoice.
- Client logs in and sees only their projects, updates, files, and invoices.
RULES / PERMISSIONS:
- Clients can only read rows tied to their own client_id.
- Only Admins can create, edit, or delete.
DESIGN: Clean and professional. Neutral grays with a single blue accent. Card-based layout, generous spacing, rounded corners.
ACCEPTANCE CRITERIA:
- A client never sees another client's data.
- Admin can complete the full create-to-invoice flow.
- Every list has loading, empty, and error states.
Start by writing a PRD and a build plan. Do not write any code yet.Notice the last line: it tells Lovable to plan first. That single instruction saves credits and catches mistakes before any code exists.
The build workflow
The order you build in matters as much as the prompts. This sequence keeps projects stable and cheap.
- Set up the Knowledge file first. The Knowledge file is your project's brain: a lightweight PRD (vision, users and personas, features, design system, roles and permissions) that is sent with every prompt. Fill it in before you build so Lovable stays on-brand and on-scope.
- Plan in Chat mode. Use Chat Mode / Plan Mode to ask for a PRD or a step-by-step plan. Chat mode answers and plans without editing code, so it is lighter on credits. Correct the plan here.
- Build one scoped step at a time in Build mode. Build Mode is autonomous: it edits code, debugs, and can web-search. Give it one feature or screen per prompt so it does not wander.
- Use Visual Edits for small tweaks. Click any UI element to change text, color, or spacing with no prompt and no credits.
- Connect the Supabase backend after the UI is stable. Build and stabilize the frontend first, then wire data, auth, storage, and RLS. Rewiring a moving UI wastes credits.
- Run a security review. Security scans run during builds, but for sensitive data get an independent review before you publish.
- Publish. One-click publish, then attach a custom domain.
On credits: they come from one unified pool (build + cloud + AI). Free is 5 a day; Pro is $25/mo for 100. Chat mode and Visual Edits are the cheap tools, so plan and polish with them and reserve Build mode for real changes. Keeping prompts scoped is the single biggest credit saver.
10 example prompts
Ten prompts that map to the workflow above. Swap the placeholders for your project.
1. Set up the Knowledge file / PRD
Draft the Knowledge file for this project as a short PRD I can paste in. Cover: one-line vision, target users and personas, the top 5 features, the core data entities, user roles and permissions, and a simple design system (colors, font, spacing, component style). App: [ONE-LINE DESCRIPTION]. Keep it under 400 words and use headings. Do not write any app code.2. Full-app spec
Build [APP NAME]. Goal: [OUTCOME]. Users/roles: [ROLE A can..., ROLE B can...]. Data: [ENTITY (fields); ENTITY (fields)]. Screens: [PAGE: what's on it; PAGE: what's on it]. Workflows: [KEY FLOW END TO END]. Rules: [WHO CAN SEE/DO WHAT]. Design: [STYLE, COLORS, TONE]. Acceptance: [HOW I'LL KNOW IT WORKS]. First write a PRD and a build plan and wait for my go-ahead before writing code.3. Add authentication
Add email + password authentication using Lovable Cloud (Supabase auth). Add a Sign up, Log in, and Log out flow, protect all app routes so only signed-in users reach them, and redirect signed-out users to Login. Store the user's role on their profile. Do not change any existing page layouts or styles.4. Design the database schema
Design the Supabase schema for these entities: [ENTITY 1: fields], [ENTITY 2: fields], [ENTITY 3: fields]. Add primary keys, foreign keys, timestamps, and sensible indexes. Add row-level security so a user can only read and write rows tied to their own account. Show me the schema and RLS policies as a plan first, before creating anything.5. Add a CRUD feature
Add full CRUD for [ENTITY] on a new page at /[route]. Include a table listing existing rows, a "New [ENTITY]" form, inline edit, and delete with a confirm dialog. Validate required fields: [FIELD, FIELD]. Wire it to the [table] table via Lovable Cloud. Only touch this new page and its components; do not modify other pages or the schema of other tables.6. Stay-in-scope edit
On the [PAGE] page only, change [SPECIFIC ELEMENT] to [NEW BEHAVIOR/TEXT/STYLE]. Do not modify any other pages, shared components, global styles, or the database. If this change requires touching anything outside [PAGE], stop and tell me first.7. Debug (paste the error)
I'm getting this error when I [ACTION]:
[PASTE THE FULL ERROR MESSAGE / STACK TRACE]
Expected: [WHAT SHOULD HAPPEN]. Actual: [WHAT HAPPENS]. Find the root cause and fix it with the smallest possible change. Explain what was wrong in one sentence. Do not refactor unrelated code.8. Make it responsive
Make the whole app fully responsive for mobile (down to 360px), tablet, and desktop. Collapse the sidebar into a hamburger menu on mobile, make tables scroll horizontally or stack into cards, and ensure tap targets are at least 44px. Keep the existing desktop design intact; only add responsive behavior.9. Add loading, empty, and error states
Add proper UI states to every page that loads data. For each list and detail view add: a loading skeleton while fetching, a friendly empty state with a clear call to action when there's no data, and an error state with a retry button when the request fails. Match the existing design system. Do not change the data logic itself.10. Publish + custom domain
Before we publish, run a security review of the app: check RLS policies, exposed keys, and any route that leaks data across users. List anything risky. Once that's clean, publish the app, then walk me through connecting my custom domain [yourdomain.com] step by step.Mistakes to avoid
- Vague one-liners. "Build me a CRM" forces Lovable to guess the data model, roles, and screens. Use the 8-part formula instead.
- Stacking many changes in one prompt. Asking for auth, a new feature, and a redesign at once makes builds fragile and hard to review. One scoped task per prompt.
- Wiring the backend before the UI is settled. Connecting Supabase while the frontend still moves means you re-wire it repeatedly and burn credits. Stabilize the UI first.
- Not using the Knowledge file. Without a PRD sent on every prompt, Lovable drifts off-brand and off-scope. Set it up before building.
- Not saying what to keep unchanged. If you do not name what to leave alone, Lovable may "improve" working pages. Add a "do not change" line.
- Shipping sensitive data without a security review. Build-time scans help, but get an independent review of RLS and exposed keys before you publish anything handling personal or payment data.
Frequently Asked Questions
What makes a good Lovable prompt?
A good prompt is specific and scoped. It names the outcome, the users and roles, the data (entities and fields), the screens, the workflows, the rules, and how you will know it works. It also says what to leave unchanged. Vague one-liners force Lovable to guess, and guesses cost credits.
Should I use Chat mode or Build mode first?
Start in Chat mode (Plan mode). Ask Lovable to write a PRD or a step-by-step plan without editing code. Chat mode is lighter on credits and lets you correct the plan before any build happens. Switch to Build mode only once the plan looks right, then build one scoped step at a time.
How do I stop Lovable breaking things that already work?
Scope every prompt and state what must not change. Say the exact component or page to edit and add a line like "Do not modify any other pages, styles, or the database schema." For tiny text or color tweaks, use Visual Edits, which changes the UI directly without a prompt.
How do I save credits on Lovable?
Plan in Chat mode, which is cheaper than Build mode, and use Visual Edits for text, color, and spacing tweaks since those cost no credits. Keep each build prompt small and scoped so Lovable does not redo unrelated work. The free plan gives 5 credits a day; Pro is $25/mo for 100.
How big should one prompt be?
Big enough to fully describe one feature or screen, small enough that Lovable can finish it in a single pass. For the first build you can hand over a full 8-part app spec. After that, prefer one scoped task per prompt: add auth, then add a feature, then add states, rather than stacking them together.
Do I need to know how to code to use Lovable?
No. Lovable turns plain English into a React and Tailwind app and wires a Supabase backend through Lovable Cloud. Knowing the basics helps you review output and debug, but you can build and publish a working app by describing what you want clearly and iterating.