Home › Rules › Lovable prompts
Lovable prompts that work: 17 copy-paste examples for beginners
Short answer: a good Lovable prompt asks for one change, says where it goes, and says what to leave alone. Below are 17 prompts in the order you'll need them, from the first message to publishing. Fill in the [brackets] and paste.
Do this first: paste a short rules block into Project settings → Knowledge so you don't repeat yourself in every prompt. Free template: Lovable Project Knowledge template.
The 4-part prompt formula
| Part | Example |
|---|---|
| 1. What to build | "Add a filter dropdown to the orders table…" |
| 2. Where it goes | "…on the orders page only." |
| 3. What stays untouched | "Keep the table's styling. Don't change anything else." |
| 4. How you'll check it | "Tell me how to test it in the preview." |
Parts 1 to 3 come straight from Lovable's prompting guide. Part 4 is our addition: it makes the AI tell you what "done" looks like.
Before you build: plan, then one step
Kickoff: plan first, then ask me questions
I want to build [one sentence: what the app is and who it's for].
The one thing version 1 must do: [the key action a user takes].
Don't build anything yet. First give me a short plan: the pages, the data you'll store, and the order you'd build it in, in 5 to 8 small steps.
Ask me any questions you need in order to fully understand what I want.Why it works: Lovable's own guide suggests ending with a request for clarifying questions, and Plan mode suits it. You catch the wrong idea before it costs credits.
Build only step 1
Build step 1 of the plan only. Stop when it's done and tell me how to check it in the preview.Why it works: One step per message is the habit that saves the most credits. You test each piece before the next one lands on top of it.
Save the style once
Use this design direction for the whole app: [calm and minimal / bold and playful / premium and sleek]. Colors [colors], font [font], rounded cards, generous spacing. Reuse existing components before creating new ones.Why it works: Paste the same text into Project Knowledge so you never have to repeat it. Lovable's docs recommend saving style keywords there.
Design prompts
Landing page hero with real words
Create a hero section. Headline: "[your real headline]". Subtext: "[one real sentence]". Button: "[verb-first CTA]". Centered layout, lots of vertical space. Only change the home page.Why it works: Real copy beats "lorem ipsum": the layout gets sized for the words you'll actually use.
One section at a time
Below the hero, add a features section: a centered headline and three cards in a row. Each card has an icon, a short title and one sentence. Soft shadow, lifts on hover. Don't change the hero.Why it works: Build by component, not by page. If one block is wrong, you redo one block.
Make it work on phones
Check every page at phone width. List anything that overflows, overlaps or is too small to tap, then fix only those things. Don't change the desktop layout.Why it works: Asking for a list first turns a vague "make it responsive" into a short, checkable to-do list.
Feature prompts (login, data, files, payments)
Login
Add email sign-up and log-in. When logged out, show a "Log in" button in the header. When logged in, show the user's email and a "Log out" button. Only add what's needed for login; don't change existing pages.Why it works: Spelling out both states (logged in and logged out) is what Lovable's guide calls building with the backend in mind.
A table that's private by default
Add a table for [items, e.g. notes] with the columns [title, body, created_at]. Each row belongs to the user who created it. Turn on row-level security so users can only read and change their own rows. Before you change the database, list the exact changes and wait for my OK.Why it works: Without row-level security, the public key in your app can read everyone's rows. Lovable's publish scan flags tables without it, but it's cheaper to ask up front.
A dashboard with empty, loading and error states
Create a dashboard page that lists the logged-in user's [items], newest first. Show a friendly message when there are none, a loading state while they load, and a clear error message if loading fails.Why it works: Most "it's broken" moments are really an empty or failed state nobody designed.
Private file uploads
Let logged-in users upload one profile picture (JPG or PNG, max 2 MB). Store it in a private storage bucket. Users can only see and replace their own file.Why it works: Buckets that are public by accident are one of the easiest leaks to make. Say "private" every time.
Payments the safe way
Add a $[price]/month subscription. The price must come from the server, never from the browser. Only mark a user as paid after the payment provider confirms it (webhook), not when they land on the success page. Explain the steps before building.Why it works: The two classic money bugs in AI-built apps: a price the browser can change, and "paid" set by visiting /success.
Fixing prompts (bugs and loops)
Report a bug so it gets fixed the first time
Bug: when I [exact steps], I expect [what should happen] but I get [what happens]. The error message is: [paste it]. Don't change anything yet. Explain the most likely cause in two sentences, then propose the smallest fix.Why it works: Expected vs actual plus the exact error is what lets the AI fix the cause instead of guessing.
Break the fix-retry loop
That fix didn't work. Stop trying fixes. Use Plan mode: list three possible causes, how to check each one, and which you think is most likely. Don't edit code until I pick one.Why it works: Retrying the same broken fix is where most credits disappear.
A small change that stays small
Change only [the exact thing, e.g. the Sign up button text to "Start free"]. Keep the existing styling and leave the rest of the app unchanged.Why it works: Lovable's docs: say what to build, where it goes, and what must stay untouched. Or select the element in the preview and edit it directly.
Before you publish
Security review before you publish
Before I publish, review this app's security: row-level security on every table, keys or secrets in front-end code, storage bucket access, and anything a logged-out user can reach. List problems by severity. Don't fix anything until I say which ones.Why it works: Lovable runs a quick security scan when you publish and offers a deeper scan; this prompt makes you read the results in plain English. Full list: our security checklist.
Basic SEO
Give every public page a unique title (under 60 characters) and meta description (under 155 characters), one H1, and descriptive alt text on images. Show me the list before applying it.Why it works: Search engines need these to show your pages at all. More in our Lovable SEO rules.
Hand off to GitHub and another tool
Write a short AGENTS.md in the project root: what the app does, the main folders, how data is stored, and the rules we've been following. Keep it under 60 lines.Why it works: Once the project syncs to GitHub, Cursor, Claude Code or Codex can pick up where Lovable left off with the same rules.
Prompts that waste credits
- "Build me an app like Airbnb." Too big for one message. Ask for a plan instead (prompt 1).
- "Make it better" / "fix it". Say what's wrong and what you expected (the bug prompt above).
- Five changes in one message. When one breaks, you can't tell which.
- Re-sending the same fix. After one failed fix, switch to the loop-breaker prompt.
Do these work in Bolt?
Yes. Everything above is plain English, so it works in Bolt's chat too. Bolt also has a Plan mode and its own Project Knowledge box, so the "plan first" prompts and the Knowledge tip carry over. Bolt-specific rules: Bolt prompt rules.
Want to try Bolt? Try Bolt
Disclosure: the Bolt link is an affiliate (referral) link. If you sign up or buy through it, VibeKits may earn a commission at no extra cost to you. It never changes our pick.
Best value
Get all 5 kits for $25 with 30% off: code WELCOME30 at checkout (through Nov 30, 2026)
These prompts handle one change at a time. The MVP Spec-to-Build Pack in our bundle gives you the whole order: a fill-in one-page spec, a landing page prompt, a 7-prompt build sequence, and a "did I leak user data?" checklist. It works in Lovable, Bolt, Replit or Cursor.
Get all 5 kits for $25 → See what's in each kit
$25 instead of $39 for the five kits bought separately; WELCOME30 takes 30% off that at checkout ($17.50). Instant download from Gumroad. 7-day refund, no questions asked.
Related
- Lovable Project Knowledge template (paste once, used on every message)
- Lovable + Supabase rules (row-level security, migrations)
- Lovable SaaS rules (Stripe, plans, webhooks)
- Lovable credits explained (what each message costs)
- Vibe coding security checklist (12 checks before launch)
- Base44 vs Lovable for beginners
- Lovable vs Bolt vs Replit (honest picks, real prices)
Sources
- Lovable docs: Prompting best practices
- Lovable docs: Prompt library
- Lovable docs: Debug and improve your app
- Lovable docs: Define workspace and project knowledge
- Lovable docs: Security overview (scans on publish)
Checked Oct 19, 2026. These tools change often; if something here no longer matches, tell us at [email protected].