Every template below is a fill-in-the-blank skeleton. Copy one, swap each [bracketed] placeholder for your own specifics — app name, exact fields, roles, colors, the page you are editing — then paste it straight into the Lovable chat box. The tighter your details, the closer the first build lands, and the fewer credits you burn re-prompting.
Keep each prompt to one scoped task: build the frontend first, add the backend after, and always say what not to change. For the highest-signal starting points, browse our best Lovable prompts, learn the end-to-end method in how to prompt Lovable for full apps, and keep the one-page Lovable prompt cheat sheet open while you work.
Plan & set up
Front-load the thinking. A Knowledge file is a persistent PRD-lite that Lovable sends with every prompt, so nailing it once keeps every later build on-brand and on-spec.
1. Knowledge-file / PRD starter
Use it when… you start a new project and want a persistent brief.
This is my project Knowledge file. Read it before every prompt and follow it.
PRODUCT: [app name]
ONE-LINE PITCH: [what it does, for whom]
VISION: [the problem it solves and why it matters]
TARGET USERS: [primary user], [secondary user]
USER ROLES: [role 1 = permissions], [role 2 = permissions]
CORE FEATURES (MVP): [feature 1], [feature 2], [feature 3]
OUT OF SCOPE FOR NOW: [thing to NOT build yet]
DESIGN SYSTEM: primary color [#hex], accent [#hex], font [font], style [minimal/playful/corporate], corners [rounded/sharp]
TONE OF VOICE: [friendly / formal / concise]
TECH: React + Tailwind frontend; Lovable Cloud (Supabase) for data/auth when needed.
Confirm you have saved this and will apply it going forward. Do not build anything yet.2. Write me a PRD before building
Use it when… you have an idea but no spec, and want Lovable to plan first.
Use Plan Mode. Do NOT edit code yet.
I want to build: [describe the app in 2-3 sentences].
Target users: [who].
Write me a short PRD covering:
1. Problem & goal
2. Target users and roles
3. Core MVP features (max [number]) and what is out of scope
4. Data model (tables + key fields)
5. Main screens and the flow between them
6. Key rules / edge cases
7. Success criteria
Ask me up to [3] clarifying questions if anything is ambiguous, then present the PRD. Wait for my approval before writing any code.3. Full-app spec (8-part)
Use it when… you are ready to hand Lovable a complete, buildable spec.
Build this app. Follow the spec exactly. Build the frontend first with mock data; do NOT add a backend yet.
1. GOAL: [what the app achieves in one sentence]
2. USERS & ROLES: [role A can…], [role B can…], [admin can…]
3. DATA MODEL: [Table1: field, field, field] · [Table2: field, field] · relationships: [X belongs to Y]
4. SCREENS: [Home], [Dashboard], [Detail], [Settings] — describe each briefly
5. WORKFLOWS: [step-by-step of the main user journey]
6. RULES: [validation, permissions, limits, edge cases]
7. DESIGN: colors [#hex/#hex], font [font], layout [sidebar/topnav], vibe [word]
8. ACCEPTANCE CRITERIA: [I can do X], [I see Y], [Z is prevented]
Start with the screens and navigation. Show me the result before adding data.Build UI
Get the interface right with mock data first. Lovable turns plain English into React + Tailwind, and you can refine visually with Visual Edits (no credits) once the structure exists.
4. Landing page
Use it when… you need a marketing page or hero for a product.
Build a single-page landing page for [product name].
Sections in order:
1. Sticky nav: logo [text], links [link1, link2, link3], CTA button "[label]"
2. Hero: headline "[headline]", subhead "[one sentence]", primary CTA "[label]", [image/illustration placeholder]
3. Social proof: [logos / stat / testimonial line]
4. Features: [3] cards — [feature: benefit] each with an icon
5. How it works: [3] numbered steps
6. Pricing: [tier names + prices] (optional)
7. FAQ: [3] questions
8. Footer: links [ ], copyright
Style: [minimal/bold], primary color [#hex], font [font]. Fully responsive. Use placeholder copy where I left blanks.5. Dashboard
Use it when… you need an authenticated home screen with metrics and data.
Build a dashboard screen. Use mock data for now.
Layout: [left sidebar / top nav] with links [ ], main content area.
Top row: [3-4] stat cards — [metric name + example value] each.
Middle: [chart type, e.g. line chart] showing [what], with a [time range] filter.
Below: a data table of [items] with columns [ ], sortable by [column], with search and a "[action]" button per row.
Right/empty state: show a friendly message when there is no data.
Style: clean, [color] accents, [font]. Responsive: sidebar collapses on mobile.6. CRUD feature
Use it when… users need to create, view, edit and delete records.
Add a full CRUD feature for [entity, e.g. "projects"]. Frontend with mock data first.
Fields: [name (text)], [status (dropdown: options)], [date], [owner], [notes (long text)].
Include:
- List view: table/cards of all [entities] with [columns], search and filter by [field]
- Create: a "[New entity]" button opening a [modal/page] form with validation
- Edit: click an item to edit the same form, pre-filled
- Delete: with a confirmation dialog
- Empty state and loading state
Keep the existing pages untouched. I will connect this to Supabase in a later prompt.7. Form
Use it when… you need a single, well-validated input form.
Build a [form name, e.g. "contact" / "onboarding"] form.
Fields (label — type — required?):
- [Full name] — text — required
- [Email] — email — required
- [Choice] — dropdown [options] — required
- [Message] — textarea — optional
- [Consent] — checkbox — required
Rules:
- Inline validation with clear error messages
- Disable submit until valid; show a loading spinner on submit
- On success show "[success message]" and [reset form / redirect to X]
- Accessible labels and keyboard navigation
Do not wire it to a backend yet — just log the payload.8. Redesign / restyle
Use it when… the app works but you want a new look, without breaking logic.
Restyle the [page/component name] only. Do NOT change any logic, routing, data, or field names — visual changes only.
New direction: [modern & minimal / bold & colorful / dark mode].
Primary color [#hex], accent [#hex], background [#hex].
Font [font], headings [weight], body [weight].
Spacing: more generous whitespace. Corners: [rounded 12px].
Buttons: [style]. Cards: [subtle shadow / flat border].
Keep all existing functionality identical. Show me before/after of the same screen.Backend & data
Once the UI feels right, turn on Lovable Cloud to wire a native Supabase project — Postgres, auth, storage, real-time and Row Level Security. Add one backend piece per prompt so nothing tangles.
9. Enable Supabase + schema
Use it when… your frontend is ready and needs real, persistent data.
Enable Lovable Cloud (Supabase) and create the database schema for this app.
Tables:
- [table_1]: [field (type), field (type), field (type)]
- [table_2]: [field (type), field (type)]
Relationships: [table_2.table_1_id references table_1] ([one-to-many]).
Defaults: [created_at = now()], [status default "…" ].
Then connect the existing [feature/page] to this data so it reads and writes real rows instead of mock data. Do not change the UI layout. Confirm the tables before wiring the frontend.10. Auth
Use it when… you need sign-up, login and protected routes.
Add authentication using Lovable Cloud (Supabase Auth).
Methods: [email + password] [and/or Google].
Screens: sign up, log in, [forgot password], log out.
After login redirect to [/dashboard]. Logged-out users hitting a protected page redirect to [/login].
Store profile fields: [display name], [avatar], [role default "user"].
Show the signed-in user's [name/avatar] in the [nav].
Protect these routes: [list]. Leave [public pages] open. Do not change the existing UI styling.11. Row Level Security policy
Use it when… each user must only see and edit their own data.
Add Row Level Security (RLS) policies so data is properly isolated.
For table [table_name]:
- SELECT: users can read only rows where [user_id = auth.uid()]
- INSERT: users can create rows only with their own [user_id]
- UPDATE / DELETE: users can modify only their own rows
- [Admins (role = "admin") can read/write all rows]
Apply the same pattern to [other tables]. Enable RLS on every table. Then confirm that a logged-in user cannot access another user's records, and show me how you verified it.12. Stripe payments
Use it when… you need paid plans or one-time checkout.
Add Stripe payments via Lovable Cloud.
Model: [subscription / one-time].
Plans: [Free: features], [Pro: $[price]/mo: features], [Team: $[price]/mo: features].
Flow: user clicks "[Upgrade]" -> Stripe Checkout -> on success mark their account as [plan] and unlock [feature].
Store the plan and status on the user's profile/subscription record.
Add a "[Manage billing]" link to the Stripe customer portal.
Gate [premium feature] behind an active paid plan; show an upsell to free users.
I will add my Stripe keys as secrets when prompted. Test mode first.13. External API + secret (edge function)
Use it when… you call a third-party API and must hide the key.
Add an integration with [API name, e.g. OpenWeather / OpenAI].
Create a secure edge function that:
- Reads the API key from a secret named [API_KEY_NAME] (never expose it to the client)
- Accepts input [ what the frontend sends ]
- Calls [endpoint / does what]
- Returns [ shape of the response ] to the frontend
Then wire [button/page] to call this function and display [result].
Handle errors gracefully with a user-friendly message and a loading state.
Prompt me to paste the [API_KEY_NAME] secret. Do not hardcode any keys.Edit, fix & ship
Iteration is where projects break. Scope every change, paste real error text when fixing bugs, and sync to GitHub so you can always roll back. Then publish with one click and lock down the security basics.
14. Scoped edit
Use it when… you want a precise change and nothing else touched.
Make ONE change only.
CHANGE: [exactly what to change, e.g. "on the Dashboard, move the 'Add' button to the top-right and make it blue"].
DO NOT change: any other page, the data model, routing, existing styling elsewhere, or any working feature.
If your change would affect anything beyond [the named element], stop and ask me first. Show me only the affected screen when done.15. Bug fix
Use it when… something errors or misbehaves and you have the message.
Fix this bug. Diagnose the root cause before editing.
WHAT HAPPENS: [describe the broken behavior]
WHAT I EXPECT: [correct behavior]
STEPS TO REPRODUCE: [1… 2… 3…]
ERROR MESSAGE:
"""
[paste the full error / console output here]
"""
First tell me the likely cause in one or two sentences. Then apply the smallest fix that resolves it without changing unrelated code. After fixing, confirm the reproduction steps now pass.16. Make responsive
Use it when… the layout breaks on phones or tablets.
Make [page/component name] fully responsive. Do not change desktop behavior or any logic.
- Mobile (<640px): [stack columns / collapse sidebar into a hamburger menu / full-width buttons]
- Tablet (640-1024px): [2-column grid]
- Desktop: keep current layout
- Ensure tap targets are at least 44px, text is readable, and nothing overflows horizontally.
- Fix [specific broken element, e.g. "the table scrolls off-screen"].
Test at 375px, 768px and 1280px and describe how each looks.17. Loading / empty / error states
Use it when… data-driven screens feel bare or janky.
Add proper states to [page/feature] without changing its layout or logic.
- LOADING: show [skeletons / spinner] while data fetches
- EMPTY: when there are no [items], show a friendly message "[copy]" plus a "[primary action]" button
- ERROR: on a failed fetch, show "[error copy]" and a "Retry" button
- SUCCESS toasts: after [create/update/delete], show a brief "[message]"
Keep it consistent with the current design. Apply the same pattern to [other data screens].18. Publish + custom domain + security review
Use it when… the app is ready to go live.
Prepare this app for launch.
1. SECURITY REVIEW: confirm RLS is enabled on every table, no secrets or API keys are exposed to the client, auth protects all private routes, and forms validate input server-side. List anything risky and fix it.
2. POLISH: check responsive layouts, empty/error states, and that no console errors remain.
3. PUBLISH: publish the app and give me the live URL.
4. CUSTOM DOMAIN: walk me through connecting [yourdomain.com], including the DNS records I need to add.
5. Sync everything to GitHub.
Report what you changed and anything I still need to do manually.Frequently Asked Questions
How do I use these templates?
Copy a template, fill in every [bracketed] blank with your own details, delete anything that does not apply, then paste it into the Lovable chat box. Each template is a scoped, single-task prompt, so run them one at a time and review the result before moving on.
What goes in the [brackets]?
Brackets are placeholders for your specifics: the app name, the exact fields, the user roles, the page you are editing, the error text, the color or font. Replace the placeholder and its square brackets with concrete values. The more precise you are, the closer the first build lands.
Which template builds a whole app?
Use the eight-part full-app spec template in Plan & set up. It covers goal, users and roles, data model, screens, workflows, rules, design and acceptance criteria. Pair it with a Knowledge file so the plan is sent with every prompt, then build the frontend first and add the backend after.
How do I add a backend?
Enable Lovable Cloud, which wires a native Supabase project with Postgres, auth, storage and Row Level Security. Use the enable-Supabase template to describe your tables, the auth template to add sign-in, and the RLS template so each user only sees their own rows. Build backend features one at a time.
How do I stop Lovable from breaking working features?
Use the scoped-edit template and name exactly what to change and what to leave untouched. Keep each prompt to one task, work in Chat or Plan Mode to review the approach first, and sync to GitHub often so you can roll back if something regresses.
Where do I learn the full method?
Read our full walkthrough at how to prompt Lovable for full apps. It shows the frontend-first, backend-after workflow, how to structure a Knowledge file, and how to keep credits low while shipping a complete app.