Lovable Prompts: 22 Templates for No-Code App Building

TL;DR: Lovable prompts carry product decisions that a chat prompt never has to: the data model, the auth rules, the empty and failure states. Lovable publishes its own prompting playbook, and this page follows it, adds 22 copy-paste templates organised by build stage, and marks where the tool stops and engineering starts.

What makes Lovable prompts different from ChatGPT prompts?

A chat prompt produces text you read once and throw away. A Lovable prompt produces files, routes, database tables and access rules that every later prompt has to live with. The cost of a vague instruction is not a mediocre paragraph. It is a schema you did not choose.

That difference has a specific consequence. Every product decision your prompt leaves open, the generator closes for you. Ask for a booking page and something decides whether a booking belongs to a user, whether two people can hold the same slot, what the page shows before any bookings exist, and what happens when the save fails. You will inherit all four answers, and you will discover three of them later, in front of a real user.

So the useful mental model is not better phrasing. It is deciding first, then writing the decisions down. Lovable's own guidance points the same way. Its prompting playbook tells you to anticipate "what happens if the data is empty, still loading, or fails?" while you are still designing the layout, before a backend exists. Those three states are where generated apps look finished and are not.

The second difference is accumulation. A chat conversation resets. A Lovable project does not, because prompt seven edits what prompts one through six built. Lovable's guide to building a real product puts the habit bluntly: "Small prompts compound. Big prompts collapse into changes you did not ask for and cannot untangle."

What does Lovable's own prompting documentation say?

Lovable publishes three prompting pages, and they are better than most of what ranks for this query. The playbook at docs.lovable.dev/prompting/prompting-one organises technique into four phases; prompting-library carries ready-made prompts by feature; prompting-debugging covers what to send when things break. All three were read in full on 27 August 2026.

The four-phase spine is Lovable's, not ours. It is worth learning because the phases map onto the order in which decisions get expensive.

Two lines from that page do most of the work. On scope: "A full-page prompt gets you noise. A section-based prompt gets you signal." On safety: "A good change prompt has three parts: what to build, where it goes, and what must stay untouched."

The library page adds a rule that people ignore and then pay for: "Run one prompt at a time." Batched prompts are the most common cause of a project that nobody can debug, because when four changes land together and one breaks something, you cannot tell which.

Plan mode or Build mode: which should you prompt in?

Plan mode is for decisions and Build mode is for execution, and choosing wrong is the most common reason a session goes sideways. Lovable's docs are unambiguous on the first: "Plan mode never modifies your code." Every message in it costs one credit. Build mode applies changes directly, and Lovable states that "Build mode pricing is usage-based", scaled to how much work the request actually caused.

Both surfaces were renamed, which is why so much published Lovable advice describes buttons that are no longer there. Lovable's docs label them "Plan mode (previously Chat mode)" and "Build mode (previously Agent mode)". If a tutorial tells you to switch to Agent mode, it was written against an older UI and its prompt advice may be equally stale.

The rule that holds up in practice: if you cannot state the change in one sentence, start in Plan mode. Schema design, a feature you have not scoped, a bug that survived two fix attempts, and any change to auth or payments all belong there first. Everything else can go straight to Build mode.

One more piece of current shape worth knowing before you prompt: new Lovable projects are built on TanStack Start, which renders pages on the server. Lovable's upgrade page states that "it became the default for new projects on May 13, 2026". Older projects on the React and Vite stack can be migrated in place. It matters for prompting because server-rendered pages behave differently for search engines and link previews, so prompts about SEO or metadata land differently on the two stacks.

The twenty-two templates below are ours. The technique underneath them is Lovable's, taken from the three prompting pages above and its guide to building a real product. Everything attributed to Lovable is quoted from a page we read; the source list is at the end. Anything beyond those pages is our own craft.

How do you write the first prompt for a new app?

Small, story-shaped, and with no database. Lovable's guide recommends describing one screen, one user and one action, with sample data, because everything else is easier to add to something that already works. Its own worded advice is to "build frontend-first", so early sessions are about the product rather than the data model.

Build the one screen that fixes this problem:

Who: [person], who currently [the painful manual workaround].
What they do on this screen: [the single key action].
What they see afterwards: [the confirmation or result].

Use realistic sample data. No login and no database yet.
Tone: [two or three words, e.g. warm and professional].
Include empty, loading and error states even with sample data.

I want to build [one-sentence description of the app].
Before you build anything, ask me the five questions you would need answered
to build this well. Do not write code yet.

Here is my app idea: [paste the description].
Break it into features I can build and test one at a time, ordered so that
each step produces something I can click through end to end.
For each step, list what it depends on and what could go wrong.

The third one belongs in Plan mode. It is the cheapest hour you will spend on the project, because the ordering it produces is what stops feature four from requiring a rewrite of feature two.

How do you prompt the data model?

Prompt it when data has to survive, and not before. Lovable's guide names the moment precisely: "The moment information has to survive a page refresh or be shared between users". Until then sample data iterates faster.

When you do cross that line, spell out the fields. A generator asked to save bookings will invent a schema; a generator handed six named columns builds the one you meant.

Store [thing] in the database with these fields:
[field] ([type], required/optional), one per line.

Wire [the existing form] to save real records, and [the existing page]
to read them. Include empty, loading and error states.
Do not change any other page.

Before you build: propose the database tables for [feature], including
field names, types, relationships and which fields are required.
Explain what happens to existing rows if I later need to [likely change].
Do not write any code until I approve the schema.

I need to add [new field] to [existing table] without losing existing data.
Show me the migration you plan to run, what it does to rows that already
exist, and how the UI should handle records where the new field is empty.
Wait for my approval before running it.

Run all three in Plan mode. Schema is the decision that is cheap now and expensive in three weeks, and reverting a Lovable version restores your code rather than your database rows.

How do you prompt auth and access rules?

Say who can see what, in the same prompt as the feature. Lovable's security guidance notes that it "sets up basic RLS policies automatically, but you should review and adjust them early in development", which is a polite way of saying the defaults are a starting point rather than a decision.

Add user accounts: signup, login and password reset, styled to match the
existing app. Require login before [protected area].
Show clear inline validation, error and success states on every form.
Do not change the public marketing pages.

Add roles: [role A] can [permissions], [role B] can [permissions],
[role C] is read-only.
Hide navigation items a role cannot use, and enforce the same rules on the
data itself so a lower role cannot modify records through direct requests.
List the policies you created and what each one allows.

Review data access for [table]. For each policy, tell me in plain English
who can read, insert, update and delete rows, and show me one example of a
request that should be blocked. Report only. Do not change any code yet.

How do you prompt one screen without touching the rest?

Name the screen, the sections in order, and the states. Lovable's playbook is explicit that building by component beats building by page, and the same logic applies to a change: the smaller the target, the less collateral damage.

Build the [screen name] page.

Sections in order:
1. [section], containing [elements]
2. [section], containing [elements]
3. [section], containing [elements]

States: empty ([what the user sees with no data]), loading, error.
Responsive: [desktop layout] on desktop, [what changes] on mobile.
Style: match the existing app. Do not introduce new colours or fonts.
Only create or edit files for this page.

On the [page name], change only this: [the exact change].
Keep the existing layout, typography, colours and spacing.
Do not touch [named neighbouring feature] or the navigation.

The second prompt is deliberately boring. Lovable's own advice is to treat these as adjustments rather than replacements, using words like replace, update and adjust instead of "make this better", which is an instruction the generator can only interpret as permission to rewrite.

How do you prompt an integration?

Name the service, then name the trigger and the failure path. Lovable ships connectors for a long list of services and can integrate arbitrary REST APIs when no connector exists, so the useful part of your prompt is the behaviour, not the plumbing.

When [event happens in my app], send [what] to [service].
Trigger: [exact condition].
Payload: [the fields that matter].
On failure: [retry / log / show the user what].
Store the credentials securely on the server. Never put a key in frontend code.
Tell me what I need to connect before this will work.

Integrate [API name]. Base URL: [url]. Authentication: [method].
Endpoints I need: [list, with what each returns].
Build a thin server-side wrapper, handle rate limits and non-200 responses,
and surface a readable error in the UI rather than a blank screen.
Do not call this API from the browser.

Lovable's security guidance is direct about why the last line is there: secrets stored in frontend code are visible to users and should be treated as compromised. Ask for the key to live server-side, and ask again in the review prompt later.

How do you prompt for a look you actually want?

Give it a style direction in words, early, and then reuse the same words. Lovable's playbook argues that visual language is a foundation rather than a polish layer, and that style words meaningfully change typography, spacing, shadow, border radius and colour. It publishes a reference of twenty named style directions with the keywords that go with each.

Design [the app or page] as [style direction]:
[four or five keywords from that direction].
Typography: [font or feel]. Spacing: [tight / generous].
Motion: [none / subtle transitions / expressive].
Apply this direction to every new section from now on.

Take a critical pass across the whole app. Tighten typography and spacing.
Improve empty states and loading states. Fix anything that feels generic.
Do not add features. Do not change colours unless something is unreadable.
List what you changed when you are done.

Then stop retyping it. Lovable's knowledge feature holds persistent instructions that are always part of the context, up to "10,000 characters" for a project, which is where a design direction belongs after the second time you describe it.

What do you prompt when the build breaks?

Describe the symptom, the location, the expectation and the actual result. Lovable's debugging page opens with the reason: "Lovable fixes what you can point at." Nothing works is not a bug report.

[What is broken], on [which page], when I [exact steps to reproduce].
Expected: [what should happen].
Actual: [what happens instead].
[Paste the console or backend error if you have one.]
Investigate the root cause before changing any code.

This error keeps coming back after [n] fix attempts.
List what we have already tried so we do not repeat ourselves, explain in
plain terms why it happens, then propose a different approach that avoids
the problematic area entirely. Do not change code yet.

[Feature] worked [when]. Review your recent changes to it, identify which
change broke it, and explain what you found before fixing anything.

Do the last two in Plan mode, and do them early. Lovable's own warning is that "Repeated blind fixes tend to pile up code that hides the real problem", which is the most accurate sentence anyone has written about this class of tool. Its docs also note that your account includes 10 free fixes via the one-click Try to fix button, each becoming available again 24 hours after use, so the free attempts are finite and worth spending on genuine one-liners rather than on structural bugs.

How do you iterate without wrecking what already works?

Change one thing, name what must not move, and bookmark the version that worked. Lovable's guide compresses the habit into six words: "one change per prompt, verify in the preview, then move on".

[The change you want], on [exact location].
Do not change: [list the pages, components or flows that must stay identical].
If this change requires touching anything on that list, stop and tell me
what and why before proceeding.

Build [feature] in steps, and wait for me to confirm each one:
1) create the page, 2) add the UI with sample data,
3) connect the data, 4) add logic and edge cases.
Do not start step 2 until I say the first step is right.

The next change is in a critical part of the app, so proceed with caution.
Examine all related code first, avoid modifying unrelated components, and
pause and explain if anything is uncertain.
Task: [the change].

I reverted the project to before [feature]. Let's implement it again in
smaller steps this time. Start with [the first step only] and stop there.

If you have watched a coding model quietly rewrite files you never mentioned, the pattern is the same one covered in why AI rewrites code you did not ask it to touch. The fix in both cases is a named boundary, not a politer request.

Where does Lovable stop and real engineering start?

At the line where being wrong costs someone else something. Lovable produces real applications, and it also produces things that look finished and are not, because a preview with sample data cannot show you a missing access policy or an unhandled failure path.

Three areas deserve review by someone who can read the generated code, regardless of how confident the chat sounds. Authentication and access rules, because a broken policy is invisible until it is exploited, and Lovable's own guidance states that "All authentication decisions must happen server-side, not in the browser". Payments, because a checkout that silently fails after taking money is a support incident rather than a bug. Personal data, because whatever you store you are now responsible for, and the app builder is not a party to that obligation.

The tell that you are past the line is usually the same: you cannot describe what the code does, only what the screen does. Lovable's security guidance is unusually candid on this point, noting that "Frontend validation improves user experience but provides no security guarantees". That is a sentence about generated code in general, not just theirs.

None of this means non-technical builders should stop. It means the shipping checklist has one extra item: before an app touching logins, money or personal data meets strangers, someone reads the access policies and the server-side code. That review is hours, not weeks.

Does a prompt library actually help with an app builder?

Partly, and it is worth being precise about which part. We make a prompt tool. We do not build apps, we do not generate code, and nothing we ship will review your access policies. Anyone telling you a prompt library replaces engineering judgement on an auth flow is selling you something.

What a library does help with is the repetition. Across a single project you will write the same six shapes over and over: the scoped change with a named boundary, the schema proposal, the access-rule audit, the bug report, the staged feature, the polish pass. Those are prompt templates with slots, and retyping them from memory is how the boundary line gets dropped on the prompt where it mattered. Saving them once, with variables for the page and feature names, is the whole benefit. That is the same argument as building a personal AI prompt library, applied to a build surface instead of a chat.

The second genuine help is upstream. In our experience the bad Lovable sessions start with a prompt that names a goal and no constraints, and the fastest fix is to expand the vague version into the specific one before you send it. That is what a prompt generator or enhancer is for, and it is a different job from building the app.

Prompt Architects lists Lovable among the platforms its browser extension supports, so the sidebar and saved prompts are available in that tab rather than in another window. Every plan includes built-in AI, so there is no separate API key to configure. What it cannot do is take responsibility for what the generated app does with a stranger's password, and no prompt tool can.

The build-stage prompt checklist

Nine checks, in the order the decisions get expensive:

1. Scaffold — one screen, one user, one action, sample data, no database.
2. Interview — ask Lovable what it needs to know before it writes anything.
3. Sequence — break the idea into steps in Plan mode, each independently clickable.
4. Schema — propose the tables and approve them before any code is written.
5. Access — name who can read and write what, then ask what a blocked request looks like.
6. Screen — sections in order, plus empty, loading and error states, every time.
7. Boundary — every change prompt names what must not move.
8. Break — symptom, location, expectation, actual, and root cause before fix.
9. Bookmark — save a version after every working feature.

Skip any one of them and the tool will make that decision on your behalf. It usually makes a reasonable choice. The problem is that you will not know which choice it made until something depends on it.

Sources and access date

Every Lovable claim here was read on 27 August 2026 at Lovable's own documentation, not from a summary. Surfaces here get renamed often, so check before relying on a detail:

• Prompting best practices: docs.lovable.dev/prompting/prompting-one
• Prompt library: docs.lovable.dev/prompting/prompting-library
• Debug and improve your app: docs.lovable.dev/prompting/prompting-debugging
• How to build a real product with Lovable: docs.lovable.dev/tips-tricks/from-idea-to-app
• Plan mode and Build mode: docs.lovable.dev/features/plan-mode and docs.lovable.dev/features/agent-mode
• Security best practices: docs.lovable.dev/tips-tricks/security-best-practices
• Plans and credits: docs.lovable.dev/introduction/subscription-plans and lovable.dev/pricing

One inconsistency is worth knowing about, because it will confuse you if you read both pages in one sitting. The pricing page's FAQ still calls the execution mode Default Mode while the documentation calls it Build mode, and the two pages give different illustrative credit costs for the same example prompt. Treat every credit figure on either page as illustrative rather than a quote.