Lovable Prompt Library

Copy-paste prompts that name the screen, the one change, and the non-goals. Built from the loops that show up on r/lovable. Free, no signup. Not official Lovable prompts.

First prompt

Start with a spec, not “build me an app”.

Build mode

First prompt: landing page

You need one page that explains the product and captures an email. Nothing else.

Build a single marketing landing page for [APP_NAME].

One job: [ONE_JOB].
Audience: [AUDIENCE].

Sections, in this order:
1. Nav with the product name and one primary CTA
2. Hero with a concrete headline, one subline, and an email capture
3. 3 benefit cards (no generic “fast / simple / powerful”)
4. How it works in 3 steps
5. FAQ with 4 real objections
6. Footer with a contact email

Non-goals: no login, no dashboard, no blog, no pricing table, no placeholder “Lovable” copy.
Design: clean, lots of whitespace, one accent color, Inter or similar. Mobile first.
Use a real product voice. No lorem ipsum.

If the idea is still fuzzy, generate a spec first instead of pasting this raw.

Build mode

First prompt: one-job SaaS

You want an app, not a landing page. Keep v1 to one user and one loop.

Build the smallest useful web app for [APP_NAME].

Who: [AUDIENCE].
The one job: [ONE_JOB].

Pages:
- / marketing page with a “Get started” CTA
- /app the signed-out wall plus the signed-in workspace
- /app workspace: list, create, edit, delete for the one object ([OBJECT])

v1 includes: email/password auth, a simple empty state, and success/error toasts.
v1 does not include: teams, roles, billing, admin, dark mode, AI, or a second object type.

When signed out, /app shows a short login/signup. When signed in, it shows only that user’s rows.
Design: calm SaaS, one accent, no stock illustrations. Write real microcopy.
Do not invent extra pages.

Auth and Stripe in the first prompt is how chats explode. Add them next.

Build mode

Lock the scope before it grows

Lovable keeps “helpfully” adding pages. Paste this when the app starts bloating.

Stop adding features.

Do not create new pages, routes, tables, or components.
Do not restyle the app.
Do not rename things.

Only fix what is already broken on [SCREEN].
If something is missing, tell me in one sentence instead of building it.

Use this as a prefix on almost every later prompt.

Stop the loop

Plan, revert, one change. This is how credits die.

Plan mode

Diagnose in Plan mode first

The same Build prompt failed twice. Do not send it a third time.

Do not write or edit any code.

The bug: [BUG].
What I expected: [EXPECTED].
What I see: [ACTUAL].
Where: [SCREEN or URL].

List the 3 most likely causes, in order.
For each cause: which file, what to inspect, and the smallest fix.
Recommend one approach. Wait for me before changing anything.

Plan mode is 1 credit and does not touch the repo. Use it before another Build loop.

Build mode

Revert and try a different approach

The last edit made it worse. Do not pile a fix on a broken fix.

Revert the last change related to [BUG].

Do not try the same approach again.
Do not restyle anything.
Do not refactor unrelated files.

Implement this approach only: [NEW_APPROACH].
Afterward, tell me which files changed and how to verify it in the UI.

If you cannot name the new approach, go back to Plan mode.

Build mode

One screen, one change

You have a working app and a small fix. This prompt is a seatbelt.

Only touch [SCREEN].

Change: [ONE_CHANGE].

Do not edit auth, the database schema, routing, or global styles.
Do not “improve” nearby copy or spacing unless it is required for this change.
If the change needs a schema update, stop and say so instead of doing it.

Replace [SCREEN] with a real name: “homepage header”, not “the UI”.

Authentication

Login that survives refresh and a custom domain.

Build mode

Add email auth without a redesign

The UI works. Now you need signup/login. Keep the existing screens.

Add email/password authentication with Supabase.

Keep every existing page and style.
Signed-out users hitting /app see login and signup.
Signed-in users see the current workspace.
Add a logout control in the existing nav, not a new dashboard chrome.

Do not add Google, magic links, profiles, or teams in this step.
Do not restyle the marketing page.
Afterward, list the redirect URLs I must add in Supabase for localhost and production.

Then add the production domain in Supabase Auth URL config before you share the link.

Build mode

Fix login on the custom domain

It works on preview. It 404s or bounces on the real domain.

Login works on the Lovable preview and fails on [PRODUCTION_DOMAIN].

Do not restyle anything.
Do not change the visual login form.

Update auth redirects and site URLs so this works:
- https://[PRODUCTION_DOMAIN]/**
- http://localhost:5173/**

Show me the exact values to paste into Supabase Auth URL configuration and any OAuth provider.
Then make the smallest code change so the client uses those URLs.

Google/GitHub also need the live origin. Generate the exact URLs first, then paste this.

Build mode

Keep the session after refresh

Login works, then a reload kicks the user out. Classic launch bug.

A signed-in user who hard-refreshes /app is treated as logged out.

Do not restyle the app.
Do not add a new auth provider.

Find why the session is not restored on load (missing session check, race, or protected route).
Fix only that.
Then tell me how to verify: login, refresh, open a private window, logout.

If this fails twice, switch to the Plan diagnose prompt with the console error.

Payments

Checkout is easy. Unlocking after pay is the work.

Build mode

Add Stripe checkout for one plan

One paid thing. Not a billing portal, not four tiers.

Add Stripe Checkout for a single plan: [PLAN_NAME] at [PRICE] per [month/year].

After a successful payment, set the user as “paid” and unlock [FEATURE].
Cancelled or failed payments must not unlock it.
Keep test mode keys in env. Do not put secret keys in the client.

Do not add customer portal, metered billing, or extra plans in this step.
Do not restyle pages that are not the checkout CTA and the success/cancel return.

Then give me: the webhook URL, the events to subscribe to, and where to put the signing secret.

Preview stays test mode. Live keys only on production.

Plan mode

Diagnose a Stripe webhook without coding

You are about to paste “it still does not unlock” for the tenth time.

Do not write code.

Stripe Checkout appears to succeed. The app does not unlock [FEATURE].

Answer:
1. Which webhook events the app handles today
2. Whether the live URL is the one Stripe calls
3. Whether the signing secret matches the environment
4. Whether the user id in the session is written on the payment row
5. The single smallest fix to try next

Wait for me before editing anything.

One focused Build prompt after this beats ten “try again” messages.

Security

Assume the frontend is public.

Build mode

Turn on RLS so users only see their rows

Default Supabase tables are public. “It worked in preview” is not a policy.

Enable Row Level Security on every table that stores user data.

Each signed-in user can select, insert, update and delete only their own rows (user_id = auth.uid()).
Anonymous users get nothing.

Do not change the UI.
Do not drop columns.
If a table is missing user_id, stop and tell me instead of guessing.

Then paste the policies you added, table by table, and how to test with two accounts.

Run the security checker on the production URL after this.

Build mode

Move secrets out of the frontend

A key in the client is public. People will grep it.

Search the repo for API keys, service-role secrets, and hardcoded Stripe/Supabase secrets.

Move secrets to env / Lovable secrets.
The browser may only keep publishable / anon keys.
Never log secrets. Never echo them into the UI.

Do not restyle.
Do not rotate keys yourself — list which ones I must rotate in the dashboards.

Show a before/after of each file you changed.

Then scan the live URL with the security checker, not only the preview.

Design

Touch one surface. Do not restyle the whole app.

Build mode

Polish one spot, leave the rest

Pixel-hunting one button at a time is the most expensive habit on r/lovable.

Visual pass on [SCREEN] only. Specifically: [ELEMENT].

Do not change auth, routing, schema, or copy on other pages.
Do not introduce a new font or color system.
Do not “clean up” nearby components.

Make [ELEMENT] match the rest of the app: spacing, type size, and the existing accent color.
If you need to change a global token, stop and ask.

Batch three visual nits into one prompt instead of three.

Build mode

Mobile pass without a redesign

The desktop canvas hides overflow, tiny tap targets, and iOS zoom on inputs.

Do a mobile-only pass for a 390px-wide phone.

Fix: horizontal overflow, tap targets under 44px, text that collides, and inputs that zoom on iOS (16px+).
Do not redesign the desktop layout.
Do not change backend or auth.

Walk the happy path: [HAPPY_PATH].
List the screens you changed and what broke before/after.

Verify on a real phone after, not only the responsive toggle.

Launch

Title, share card, 404, privacy, empty states.

Build mode

Replace the default title and share card

Google and iMessage still say “Lovable App”. The first Slack share dies.

Set real SEO and social tags on the home page (and any public pages).

Title: [TITLE] (under 60 characters)
Meta description: [DESCRIPTION] (under 155 characters)
OG title / description: same intent, no “Lovable” leftover
OG image: [OG_IMAGE_PATH or generate a 1200×630 image]
Favicon: a simple mark that is readable at 16px

Do not change the in-page design except if the visible h1 disagrees with the title.
Remove any default Lovable title, description, or placeholder image.

Preview the live URL with the SEO checker and Open Graph tool after publish.

Build mode

Empty, loading and error states

A blank workspace looks broken. First-run is part of the product.

Add empty, loading, and error states for [OBJECT] on [SCREEN].

Empty: one sentence + a single CTA to create the first [OBJECT].
Loading: a quiet skeleton or spinner, no layout jump.
Error: what failed + a retry. No raw stack traces.

Do not add onboarding tours, tooltips, or a second CTA.
Do not restyle the happy path.

Write the empty state in the user’s words, not “No data found”.

Build mode

Privacy page and a real 404

You collect emails or payments. A blank root on a dead URL looks unfinished.

Add two pages. Do not restyle the rest of the app.

1) /privacy
A short privacy policy that names: [VENDORS: e.g. Supabase, Stripe, Resend, Fathom].
Say what you collect, why, and a contact email: [CONTACT_EMAIL].
Link it in the footer.

2) A real 404
Unknown routes show a short “page not found” with a link home.
No blank Vite root. No “Lovable” placeholder.

If you take money, add /terms in a separate prompt. Or generate the policy first, then paste it.

Need a first prompt for your idea, not a template?

The library covers the jobs that keep coming back. The generator writes a spec from what you actually want to ship.

Open the prompt generator

Why most Lovable prompts burn credits

Officially, a small Build-mode edit can cost 0.5 credits. On r/lovable the same people report 200, 500, then 1,000. The difference is almost never the first prompt. It is “also fix auth and make it prettier” ten times, or debugging Stripe by retrying the same sentence.

These prompts are written the other way: one screen, one change, explicit non-goals. Replace the [BRACKETS]. They are not official Lovable prompts.

How to use this library

  • First prompt for a landing page or a one-job SaaS. For a custom spec, use the prompt generator.
  • Plan mode (1 credit, no code) when the same Build prompt failed twice.
  • Auth / payments / RLS as follow-ups, never stacked into the first message.
  • Launch prompts after the product works: title, OG, 404, privacy.

Prefix almost every later prompt with the scope-lock one. If Lovable “helpfully” adds a dashboard you did not ask for, that is why.

Frequently asked questions

What is a good Lovable prompt?

It names the screen, the one change, and what not to touch. “Make it better” is how the bill explodes.

Should I put auth and Stripe in the first prompt?

No. Ship the core loop. Add auth. Then payments. Stacking them is how chats die at 500 credits. The credit estimator shows the range.

When should I use Plan mode?

When you do not know the cause, or Build failed twice. Diagnose, then send one scoped Build prompt.

Is this the same as the prompt generator?

No. The generator writes a custom first prompt from your idea. This library is reusable prompts for the jobs that keep coming back.

Before you share the link, walk the launch checklist and run the security checker.

Weekly digest

Subscribe to our newsletter

Stay curious about what's new with Lovable — get the latest projects and updates delivered to your inbox.

No spam. Unsubscribe anytime.