Lovable Prompts: 12 Copy-Paste Prompts That Build Real Apps

Good Lovable prompts name one component, hand it real content, and say what to leave alone. Vague prompts get you a generic page and a smaller credit balance, because Lovable bills Build mode by the size of the job it decides to do.

The 12 below are written for founders who don’t read code. Copy them, fill in the brackets, and paste them straight into the chat. They assume nothing about your app except that you want it finished.

Before you type anything: the two setup prompts

1. Fill the Knowledge field first. Lovable reads your project’s Knowledge on every single message, which makes it the cheapest context you’ll ever buy — write it once instead of re-explaining your app forever. Open Plan mode and paste this:

Interview me to fill in this project's Knowledge. Ask me one question
at a time about: what this app does, who uses it, the main thing they
came to do, the data we store, and the look I want. When we're done,
write the finished Knowledge entry for me to paste in, under 10,000
characters, no code.

Ten thousand characters is the hard cap on the Knowledge field, so keep it to decisions and vocabulary rather than a full spec.

2. Plan before you build. Plan mode costs a flat 1 credit per message and changes no code, while a Build message that heads the wrong direction can cost several credits plus whatever you spend undoing it. Start every non-obvious feature here:

Plan mode. I want to add [feature]. Ask me up to 5 clarifying
questions, then show me the plan: which screens change, what gets
stored, and anything you'd have to guess. Don't write code yet.

If you’ve written a one-page spec already — our PRD template is built for this — paste it in place of the description and ask for the same plan.

Building: the four prompts that make the app

3. Build one component at a time. Lovable’s own guidance is to prompt by component, and it’s also the cheaper way to work: small scoped jobs bill less than sweeping ones.

Build only the [hero section] for [page]. Nothing else on the page
yet. Use this exact copy: [paste your real headline, subhead, and
button text]. Leave every other file untouched.

4. Real content beats lorem ipsum. Placeholder text gives the AI nothing to design around, and you end up restyling everything once the real words arrive:

Here's the real content for [screen]: [paste your actual copy].
Build the layout around this text — no placeholder copy, no invented
features, no sections I didn't give you content for.

5. The style direction prompt. Aesthetic words steer typography, spacing, and color more than color codes do:

Apply this style across the whole app: [minimal / editorial /
premium / playful], [2-3 color palette], generous spacing, one
accent color used sparingly. Save these rules to Knowledge so every
new screen matches without me repeating them.

6. Copy the pattern you already have. Apps get hard to change when every screen is built a different way:

Add [feature]. Build it the same way [existing feature] works —
same components, same layout rules, same error messages. Do not add
new libraries or change anything outside this feature.

Adding a backend: the Cloud prompts

7. Accounts and login. Auth is the point where a demo becomes an app, and Lovable’s docs price “add authentication” around 1.20 credits — cheap for what it is, expensive if you ask three times:

Add email login with Lovable Cloud. Signed-out visitors see [which
pages], signed-in users see [which pages]. Every user can read and
edit only their own [records] — nobody else's. When you're done,
give me 3 steps to test this myself with two different accounts.

The “only their own records” clause is the one people skip, and it’s the difference between a private app and a public database.

8. Store the data properly. Ask for the shape before the screens:

Plan mode. My app stores [describe your data in plain English].
Show me the tables and fields you'd create, in plain English, and
flag anything a user could edit that they shouldn't be able to.

When it breaks: the fixing prompts

9. Report symptoms, never prescribe fixes. You don’t have to know what’s wrong to describe it precisely:

Expected: [what should happen]. Instead: [exactly what you saw, and
the moment it went wrong]. Find the cause before changing anything,
explain it to me in one plain-English paragraph, then fix only that.

10. Stop a repair loop before it eats your month. When the same bug survives two attempts, switch modes rather than prompting again — repeated Build attempts each bill for the work they do:

Plan mode. You've tried to fix [bug] twice and it's still broken.
Don't fix it now. Tell me what you think is happening, what you'd
try next, and what you'd need from me to be sure.

Then revert to your last working version and apply the plan once. We cover the credit math behind this habit in our Lovable review.

Before strangers arrive: the shipping prompts

11. The security pass. Vibe-coded apps fail in a short list of predictable ways, and you can name all of them in one prompt:

Act as a senior application security engineer. Check my app for:
(1) fields a user can edit that control money or access (plan,
credits, admin), (2) API keys visible in the browser, (3) data one
user can read that belongs to another, (4) missing limits on
anything that costs me money per use. Explain each finding in plain
English and wait for my approval before changing code.

The longer version, with the fix spelled out for each finding, is free on our resources page, and how to build an app with AI covers why these four keep showing up.

12. The stranger test. You know where every button is, which disqualifies you as a tester:

Review this app as a first-time user on a phone who has never seen
it. Walk the main flow screen by screen and list every point where
someone would be confused, stuck, or unsure anything happened.
Report only — change nothing.

Four habits that cut your credit bill

Prompts are half of it. How you work is the other half:

1. Change copy in the preview toolbar. Inline text edits there are free up to 100 a day per user, while asking the agent to reword a headline bills as a message.
2. Stay in Plan mode while you’re thinking. One credit flat, no matter how long the answer.
3. Scope every Build message to one change. Lovable’s published examples run from 0.50 credits for a gray button to 2.00 for a landing page with images, so you pay by the size of the ask.
4. Revert instead of repairing. Rolling back to a working version costs nothing; three rounds of “try again” cost whatever the agent spends trying.

How to write your own

Every prompt above uses the same three moves, and once you see them you can improvise:

1. Set the boundary — the one component, the one bug, the files to leave alone.
2. Give what the AI can’t guess — your real copy, the exact error, the two-account test case, the palette.
3. Ask for a check you can run — three steps to test it, a plain-English explanation, a list you approve before anything changes.

Drop the third move and you’re trusting the AI’s word that it works. If you’re weighing Lovable against the alternatives, Lovable vs Bolt vs Replit puts the three side by side, and our best AI app builders roundup covers the wider field. Building with Claude Code instead? Those prompts live here.

The bottom line

Twelve prompts cover the arc: load your context once, plan in the cheap mode, build one component at a time with real copy, add accounts with per-user rules, debug by symptom, and audit before strangers show up. Use them and your Lovable projects finish more often and cost less to finish. The part no builder handles for you is picking an idea worth building and turning it into income — that’s Software Secrets 2.0, and the whole book is free.