Lovable Prompts: 18 Copy-Paste Prompts by Job

"Build me a booking app" will get you a booking app. It just won't be yours. Lovable fills every gap you leave, and each prompt layers on the code that came before, so a lazy decision in message one is still there in message fifty. These prompts are written to close those gaps for Lovable specifically, which is why each one names a mode. For a tool-neutral set organized by build phase, see our prompt library for AI app builders.

How to use these prompts in Lovable

A warning first: plenty of older guides use names Lovable has since changed. Agent mode is now Build mode. Knowledge is now Instructions. Visual edits gave way to the preview toolbar. The advice below uses the names in the current docs.

• Chat mode discusses the app you have open and changes no code.
• Plan mode investigates the project and writes a plan you edit and approve. It never modifies code. Each message costs 1 credit, plus any subagent research.
• Build mode is the default. It applies changes across files and checks the result. Cost depends on the size of the request, so small edits usually cost less. Option+P on Mac or Alt+P on Windows and Linux cycles through the three.
• Instructions hold up to 10,000 characters per project and per workspace and are always in context. Put your design rules and "never do" list there, not in every message. Skills, loaded on demand, cover instructions that only matter on some tasks.
• The @ menu in the chat input brings in projects, connectors, code and designs.
• The preview toolbar lets you select an element and describe a change, edit text inline, or draw an annotation.
• Version history saves every change automatically. Bookmark each working state before you try something risky.

Run prompts one at a time and check the result before sending the next. Lovable's prompting best practices make the same case: you're managing a build, not writing one perfect message. Its prompt library has feature-specific starters. Still hunting for something to build? Start with our web app ideas.

Which prompt for which job

Prompts to plan the app

Lovable's docs suggest answering four questions before you start: what is it, who is it for, why will they use it, and what is the one key action? These three prompts get those answers out.

1. Pressure-test the idea (Chat mode)

Run this before any building. Chat mode cannot change your code, so a bad idea dies cheaply here.

I want to build [app idea] for [specific user, e.g. independent physiotherapists with 20 to 50 regular clients].
Today they handle this with [current workaround, e.g. a paper diary and WhatsApp reminders].
Do not build anything yet. Ask me up to 5 questions about the user, the one action that matters most, and what the app must store.
Then describe the smallest first version that would still be useful to one real user, and list 3 things to leave out of it.

2. First build spec (Plan mode)

Turns the answers from prompt 1 into a plan you can edit and approve before any code is written.

Plan the first version of [app name]. Do not write code until I approve the plan.
User: [who uses it].
Key action: [the one thing they must be able to do, e.g. book a slot in under a minute].
Screens: [list, e.g. public booking page, my bookings, admin calendar].
Data to store: [objects and fields, e.g. Booking: client name, phone, start time, status].
Out of scope for now: [e.g. payments, reminders, a second location].
Show the screens, the tables and the build order. Flag anything you had to assume.

3. Draft your project instructions (Chat mode)

Instructions stay in context on every message, so rules you would otherwise repeat belong here. Paste the result into Project settings, Instructions.

Read this project and draft text for my project instructions, under 3,000 characters.
Cover what the app does, who uses it, the main tables and how they relate, our terms ([term] means [meaning]) and the design rules ([fonts, colors, spacing]).
Add a "never do" list: [e.g. never rewrite the pricing page copy, never remove a database column without asking].
Write it as short, plain rules I can paste in as they are.

Prompts for design and UI

Lovable may ask design questions about color, typography and layout on its own when your prompt leaves them open. Answer them. For a page whose only job is to convert, our landing page prompts go deeper on that one job.

4. Pick a visual direction first (Chat mode)

Decide the look before the first screen exists. Design problems are harder to fix later.

Before building any UI for [app name], propose 3 visual directions for [audience].
For each one give a two-word name, a color palette with hex codes, heading and body fonts, corner radius, spacing density and one non-software reference for the feel (e.g. a train timetable, a paperback cover).
Say which direction suits [context, e.g. people reading on a phone between appointments] and why.
Wait for my pick, then write that direction as short rules I can save to project instructions.

5. One section with real copy (Build mode)

One block at a time, with the words a visitor will actually read.

Build only the [hero / pricing / FAQ] section of the [page name] page.
Layout: [e.g. left-aligned headline, one line of subtext, one button, product screenshot on the right].
Headline: "[your real headline]"
Subtext: "[your real subtext]"
Button: "[label that starts with a verb]", linking to [route].
Follow the design rules in the project instructions. Leave every other section of the page as it is.

6. Empty, loading and error states (Build mode)

This covers what a new user sees on day one.

On the [page name] page, add the states that are missing:
- Empty: when [list] has no items, show "[real message]" and a button to [first action].
- Loading: skeleton rows that match the final layout.
- Error: if the data fails to load, show "[real message]" and a Retry button.
- Signed out: [what a visitor sees instead].
Do not change the layout of the page when it has data.

Prompts for data and accounts

Lovable's built-in backend includes a database, authentication, storage, realtime and functions. These prompts force the access questions into the open. Our guide on prompting for backend logic, auth and payments covers the same ground for any builder.

7. Review the data model (Plan mode)

Early structure compounds, so look at the tables while they are still cheap to change.

Plan the database for [feature] using the built-in backend. No code yet.
Objects I think we need: [e.g. Client, Appointment, Invoice].
For each table show the fields, their types, which are required and how the tables relate.
Tell me which rows belong to one user, which are shared inside a team and which are public.
Point out anything I will regret later, such as data that should be its own table now or fields that will need a change history.

8. Sign-in with named methods (Build mode)

Unless you name the sign-in methods, Lovable sets up email and password, Google, and Sign in with Lovable. Say what you want.

Add login using only [email and password / Google / phone]. Do not add any other sign-in method.
Require login for [routes]. Keep [routes] public.
After sign-in, send new users to [onboarding route] and returning users to [dashboard route].
Roles: [e.g. owner and member]. A member can [allowed actions] but cannot [blocked actions].
Show me the logged-in and logged-out versions of the header.

9. Check who can see what (Plan mode)

Lovable sets up row level security rules when it builds features that store user data. The policies view is read-only, so checks and changes go through chat.

List every table in this project and, in plain English, who can read, add, change and delete its rows today.
Compare that with what I want:
- [table]: [e.g. a client sees only their own appointments]
- [table]: [e.g. team members see every appointment in their team]
- [table]: [e.g. anyone can read, only owners can change]
Show me every mismatch and the rule you would change. Change nothing until I approve.

Prompts for features and changes

This is where most apps start to wobble. A small request can ripple into parts that already work, so every prompt here draws a boundary. Prompt 13 is the exception in scale: a goal can run for up to 10 hours on one message and use a large number of credits, and it pauses at your credit check-in level (20 credits by default) to ask whether to continue.

10. A change with a fence around it (Build mode)

The everyday prompt: what to build, where it goes, what stays untouched.

Add [feature, e.g. a status filter] to [page or file, e.g. @src/pages/orders].
It should [expected behavior, e.g. filter the table by Paid, Pending or Refunded and keep the choice in the URL].
Only change [files or pages]. Do not modify [e.g. the shared layout, login or the pricing page].
Keep the existing styling. When you finish, tell me which files changed.

11. Tweak a selected element (preview toolbar)

Choose Select elements in the preview toolbar, click the element, then send this. For a plain typo, use inline text editing instead.

Change the selected [button / card / heading]: [e.g. set the label to "Book a slot" and use 24px side padding].
Keep its background color, font and position.
Apply the same change to these other instances, and no others: [none / list them].

12. Subscription tiers (Plan mode, then Build)

Built-in payments run on Paddle or Stripe and need a Pro plan or higher; on Free you can connect your own Stripe account. Checkout in the preview takes test cards only.

Plan payments for [app name]. I sell [digital product or software, e.g. a monthly subscription].
Tiers: [name, price, what it includes] and [name, price, what it includes].
Signed-in users who have not paid can [what]. Paying users can [what].
If a payment fails or a subscription is cancelled, [what happens to their access].
Tell me which payment provider you recommend for this and what I must do myself to go live. I will test checkout in the preview before publishing.

13. A large task with /goal (Build mode)

A goal does not stop to ask questions, so the message has to answer them up front.

/goal Build [feature that spans several parts of the app, e.g. team accounts].
Finished means: [pages, flows and data that must exist, e.g. invite by email, accept link, team switcher, data split by team].
Decisions already made: [look, behavior and edge cases, e.g. invites expire after 7 days, removed members lose access at once].
Already connected: [connectors and secrets the work needs].
Do not change: [areas to protect].

Prompts for debugging

When an error appears, the Try to fix button is the first stop. Your account includes 10 free fixes, and each becomes available again 24 hours after you use it. One or two tries, then switch to these. If fixes have tangled the code, restore a working version from history and rebuild in smaller steps.

14. A bug report Lovable can act on (Build mode)

Use after Try to fix has failed once or twice. Attach a screenshot if the problem is visual.

Bug on [page or route].
Steps: [1, 2, 3].
Expected: [what should happen].
Actual: [what happens, with any error text].
It worked until [last known good change, or "it never worked"]. It happens for [all users / this role / only on the published site].
Fix only this. If the cause is outside [area], stop and explain before changing anything else.

15. Root cause before another fix (Plan mode)

Blind retries pile up code that hides the real problem. Plan mode cannot touch the code.

This problem has survived [number] fix attempts: [short description].
No more patches yet. List what has been tried, what each attempt changed and what you can see in the logs and code.
Give me the most likely cause, how you would confirm it, and a fix that removes the cause rather than the symptom.
If any earlier attempts should be undone first, say which.

Prompts for launch

Run these three before you share the link, and see our best practices for AI coding if you want habits that hold up beyond one tool. If you outgrow Lovable, our list of Lovable alternatives and our Cursor prompts are the next stops.

16. Walk the main flow in a browser (Build mode)

Browser testing clicks and fills forms in a real browser. Run it as its own message: Lovable warns against asking for a large change and a test in one prompt.

Verify the main flow works, using browser testing: [e.g. sign up, create a booking, see it on the dashboard, cancel it].
Test at phone and desktop sizes.
Report each step as pass or fail, with what you saw and any console errors.
Change no code in this run. I will choose what to fix.

17. Pre-launch security read (Plan mode)

Lovable's Quick scan runs on every publish, and its docs say the scans do not replace a thorough review.

Before I publish, review this project in plain English. No code changes.
This app stores [type of data, e.g. names, phone numbers, appointment notes].
Check for API keys or secrets in frontend code, pages that should require login but do not, tables a signed-out visitor can read, actions a normal user can take on someone else's data, and forms with no server-side validation.
Rank each finding by what could go wrong for a real user.

18. Metadata for public pages (Build mode)

Lovable's docs say starting metadata is generic and a new project does not always get a sitemap. Run the SEO and AI search review in Analytics afterwards.

Write SEO metadata for each public page of this app. For every route, give a unique title under 60 characters, a description under 160 characters and one H1 that matches what the page does.
Reader: [who]. Search phrases I have checked: [phrases].
Add a sitemap if this project has none. Keep [login and dashboard routes] out of it.
Change nothing else.

Common mistakes with Lovable prompts

• Asking for the whole app in one message. Lovable's docs recommend prompting by component: build a block, review it, then move on.
• Using placeholder text. "Feature 1, Feature 2" gives Lovable nothing to respond to and hides layout problems a real headline would expose.
• Saying "make it better". Use "replace", "update" or "adjust", and name the thing being changed.
• Leaving out what must stay untouched. "Do not touch login" costs four words and can save an afternoon.
• Using /goal when you want to review along the way. It builds the finished version rather than a first draft, and decides anything you left open.
• Treating a clean scan as sign-off. Lovable says its scans cannot guarantee complete security and suggests a professional review for sensitive data.

Frequently Asked Questions

What makes a good Lovable prompt?
A good Lovable prompt says who the feature is for, what it should do, where it goes and what must stay untouched. Lovable's own best-practices guide recommends building one component at a time, using real copy instead of placeholder text, and naming specific UI parts such as cards, modals and form fields.

Should I use Chat, Plan or Build mode in Lovable?
Use Chat mode to discuss the app without changing code, Plan mode to get a written plan you can edit and approve before anything is built, and Build mode to make the change.

Do Lovable prompts use credits?
Yes. A Plan mode message costs 1 credit plus any subagent research Lovable runs while planning. Build mode cost depends on the complexity of the request and the work completed. Chat mode has its own per-message pricing.

How do I stop repeating the same instructions in Lovable?
Save them. Project instructions and workspace instructions (previously called Knowledge) each hold up to 10,000 characters and are always included in context. Skills are for instructions that only matter on certain tasks, because Lovable loads them on demand.

What should I do when Lovable keeps failing to fix a bug?
Use Try to fix once or twice, then describe the bug with steps, expected result and actual result. If it survives, move to Plan mode and ask for the root cause before any more code changes. If fixes have tangled the code, restore a working version from version history and rebuild in smaller steps.

Does Lovable have its own prompt library?
Yes. Lovable's docs include a prompting best-practices guide and a prompt library with copy-paste prompts for common features. The prompts on this page are original and organized around jobs and modes, so the two work well side by side.