How do I write a good Lovable prompt?

Structure the prompt around one outcome

A good Lovable prompt names a specific, testable result, not a vague wish. Include:

• The screen or feature (e.g. "the pricing page", "the signup form")
• What it should do and for whom
• Real content where you have it — actual copy, prices, product names, not "lorem ipsum"
• Constraints: what should stay unchanged

Add a pricing page at /pricing with three tiers: Starter, Pro, Business. Use the copy and prices from the doc I've pasted below. Match the existing header and footer — don't touch any other page.

Use design language, not just function

Lovable responds well to concrete design vocabulary: "generous whitespace", "card-based layout", "muted palette", "sticky header". Naming a reference site or attaching a screenshot (see /questions/should-i-use-screenshots-when-prompting-lovable) narrows ambiguity faster than adjectives alone.

Plan before you prompt on anything complex

For multi-step features, switch to Plan mode first and let Lovable ask clarifying questions before it writes code — see /questions/how-do-i-get-lovable-to-plan-a-feature-before-building-it. For a one-line tweak, Chat/Build mode is fine.

Build in small, verifiable steps

One feature per message beats one giant prompt covering the whole app. Small steps are easier to review, cheaper to redo if wrong, and easier to revert with Version history if something breaks. See /questions/how-do-i-make-lovable-build-one-feature-at-a-time.

What usually goes wrong

• Prompt is a wishlist, not a spec. "Make it better" or "add a full dashboard" gives Lovable too much room to guess. Break it into named pieces.
• No constraints given. Without "don't touch X", Lovable may refactor working code alongside the new feature.
• Missing real content. Placeholder text and images get built in and then need a second round of edits — paste your actual copy and upload real assets (/questions/how-do-i-upload-images-to-lovable) up front.
• Skipping review. Use the diff/preview and Version history to check each change before stacking the next prompt on top.

Save the phrasing that works for your project as reusable instructions in Project knowledge so you don't have to repeat it every time.

A prompt template that works for most Lovable builds

Copy this shape and fill in the blanks. It covers the four things Lovable needs: goal, scope, content, and guardrails.

Goal: <what the visitor should be able to do>
Page/route: <e.g. /pricing>
Sections, in order: <hero, three-tier table, FAQ, CTA>
Content: <paste real copy, prices, names>
Design: <layout style, spacing, palette, reference site>
Data: <what to save, where, who can read it>
Do not change: <existing pages/components that must stay identical>
Done when: <the test you will run to accept it>

The "Done when" line matters more than people expect. It gives you an acceptance test — "a submitted form appears in the enquiries table and sends me an email" — instead of a vague sense that something looks off.

Prompting by build stage

Stage 1 — foundation. Describe the product, the audience, the tone and the pages you need. Ask for the design system (colours, fonts, spacing tokens) to be defined once so later pages inherit it.

Stage 2 — features. One feature per prompt: auth, then roles, then the dashboard. Ask Lovable to plan first on anything touching the database.

Stage 3 — data. Name tables, columns and access rules explicitly: "each enquiry row belongs to one user; only admins can read all rows."

Stage 4 — polish. Mobile behaviour, empty states, loading states, error messages, metadata. These are cheap prompts that make a build feel finished.

Words that change the output

Instead of	Say
"make it look better"	"increase section padding, cap body width at 72ch, use one accent colour"
"add a dashboard"	"add /admin with a table of enquiries: date, name, email, status, filterable by status"
"fix the mobile issues"	"at 375px the header buttons wrap and the table scrolls the page sideways — fix both"
"add login"	"add email/password auth with a profiles row created on signup, and gate /admin behind it"

Reusable instructions

Anything you find yourself repeating — brand colours, tone of voice, "always use semantic tokens", "never change unrelated files" — belongs in Project knowledge rather than in every prompt. Lovable applies it to each message automatically, which shortens your prompts and keeps the output consistent across sessions.

Reviewing a prompt before you send it

Read it back and ask: could a competent freelancer build this without asking me a question? If not, the missing answer is exactly what Lovable will guess at. Add it, then send.