Prompt Library

Lovable AI Prompts to Build Real Apps

21 copy-paste prompts

21 copy-paste prompts that turn Lovable into a reliable app builder. Spec features precisely, wire up Supabase and Stripe, refine the UI, and fix bugs one step at a time.

In short: This page contains 21 copy-paste ready prompts, organized into 5 categories with a description and pro tip for each. The first 15 prompts are free instantly โ€” no signup needed. Hand-curated and tested by the AI Academy team.

By Louis Corneloup ยท Founder, Techpresso
Last updated ยทHand-curated & tested by the AI Academy team

Starting a New App

4 prompts

Scaffold the Core App

1/21

Build a [type of app, e.g. habit tracker] for [target users]. Start with only the core flow: [main user action]. Create a clean landing page, a single main screen, and placeholder navigation. Use React and Tailwind. Do NOT add auth, payments, or a database yet, just static UI with mock data so I can review the layout first.

Sets up the skeleton of your app without overloading the first generation. Reviewing static UI before adding logic keeps later edits clean.

๐Ÿ’ก

Pro tip: Explicitly telling Lovable what NOT to build yet prevents it from wiring up Supabase and auth before you have approved the basic structure.

Define the App in a Spec

2/21

Before building, write a short product spec for a [app idea] as a numbered list: the main pages, the key user actions on each page, and the data each page needs. Show me the spec only, do not generate any code yet. Once I approve it, we will build one page at a time.

Forces Lovable to plan in plain language first so you can correct the direction before any code exists.

๐Ÿ’ก

Pro tip: Treat the approved spec as your source of truth and paste a line from it into each follow-up build prompt for consistency.

Set the Visual Direction Early

3/21

For this app, establish a design system before building screens: a [modern / minimal / playful] style, a primary color of [hex], rounded cards, generous spacing, and a clean sans-serif font. Apply it to the landing page first so we lock the look, then reuse the same tokens everywhere.

Locks in a consistent visual language up front instead of fixing mismatched styles screen by screen later.

๐Ÿ’ก

Pro tip: Give one concrete reference (a hex color and a vibe word) rather than long adjectives, Lovable applies specific tokens far more reliably than vague style requests.

Plan the Data Model

4/21

List the database tables this [app idea] will need, with each table's columns, types, and relationships, as a plain-text outline. Do not create the tables yet. I want to confirm the schema before you connect Supabase.

Surfaces the data structure as a reviewable outline so you catch missing fields before tables are created.

๐Ÿ’ก

Pro tip: Approving the schema first avoids painful migrations later when Lovable would otherwise guess your columns mid-build.

Prompts get you started. Tutorials level you up.

A growing library of 300+ hands-on AI tutorials. New tutorials added every week.

Start 7-Day Free Trial

Adding Features Step by Step

5 prompts

Add One Feature at a Time

5/21

Add a [feature, e.g. comment section] to the [page name] page only. It should let users [specific actions]. Reuse the existing card and button components instead of creating new styles. Do not touch any other page. After building, summarize exactly what changed.

Scopes the change tightly to one page and one feature so Lovable does not silently rewrite unrelated parts of the app.

๐Ÿ’ก

Pro tip: Asking for a summary of what changed makes it easy to spot and undo unintended edits in your next message.

Reference an Existing Component

6/21

Build a [new screen] that reuses the same layout, spacing, and card style as the existing [page name] page. Match its header, padding, and button components exactly so the app feels consistent. Only the content and data should differ.

Keeps new screens visually consistent by anchoring them to a component you already approved.

๐Ÿ’ก

Pro tip: Naming a specific existing page gives Lovable a concrete pattern to copy, which beats describing the style from scratch each time.

Add a Form with Validation

7/21

Create a [form name] form with these fields: [list fields and types]. Add inline validation with clear error messages, disable the submit button until the form is valid, and show a success toast on submit. For now, log the submitted data to the console instead of saving it.

Builds a polished, validated form while deferring storage so you can confirm the UX before wiring the backend.

๐Ÿ’ก

Pro tip: Logging instead of saving lets you test the form flow safely before any Supabase write is connected.

Add Navigation and Routing

8/21

Set up navigation between these pages: [list pages]. Add a persistent top nav (or sidebar) with active-state highlighting on the current page, and make every link route correctly. Do not change the content of the pages themselves, only the navigation.

Connects your screens into a coherent app with working routes and clear active states.

๐Ÿ’ก

Pro tip: Build navigation only after the individual pages exist, so Lovable wires real routes instead of placeholder links.

Add Search and Filtering

9/21

On the [page name] page, add a search bar and filter controls for [fields to filter by]. Filtering should update the visible list instantly as the user types or selects. Keep the existing list layout and styling, only add the controls above it.

Layers interactive filtering onto an existing list view without disturbing the surrounding design.

๐Ÿ’ก

Pro tip: Specify which fields are filterable, otherwise Lovable may add filters that do not map to your actual data.

Design & UI Prompts

4 prompts

Refine a Specific Section

10/21

Improve the visual design of the [section name] only. Increase spacing between items, align the elements to a clean grid, and make the primary action stand out. Keep the existing colors and fonts. Do not change any other part of the page.

Targets one section for a design polish pass without risking a full-page restyle.

๐Ÿ’ก

Pro tip: Constraining edits to one named section is the most reliable way to get focused design changes in Lovable.

Make It Mobile-Responsive

11/21

Make the [page name] page fully responsive on mobile. Stack columns vertically below 768px, increase tap target sizes, and ensure no horizontal scrolling. Show me how it should behave at mobile, tablet, and desktop widths, and keep the desktop layout unchanged.

Adds responsive behavior to a specific page while preserving the desktop layout you already approved.

๐Ÿ’ก

Pro tip: Call out the breakpoint behavior you want explicitly, Lovable handles responsiveness much better with concrete rules than with 'make it responsive'.

Build an Empty and Loading State

12/21

Add proper empty, loading, and error states to the [page name] page. The empty state should show a friendly message and a primary action to [do something]. Loading should show skeleton placeholders, and errors should show a retry button. Match the existing card styling.

Covers the states real users hit, which most generated apps skip, making the app feel finished.

๐Ÿ’ก

Pro tip: Naming all three states (empty, loading, error) in one prompt gets them styled consistently in a single pass.

Add a Polished Landing Page

13/21

Design a conversion-focused landing page for [product] aimed at [audience]. Include a hero with a clear headline and CTA, three benefit cards, a short how-it-works section, and a footer. Use our existing color palette and keep copy concise. Build it as a new route, do not replace the app dashboard.

Produces a marketing landing page as a separate route so it never collides with your app screens.

๐Ÿ’ก

Pro tip: Ask for it as a new route explicitly, otherwise Lovable may overwrite your existing home page.

Like these prompts? There are full tutorials behind them.

Learn the workflows, not just the prompts. 300+ easy-to-follow tutorials inside AI Academy โ€” and growing every week.

Try AI Academy Free

Backend, Auth & Integrations

4 prompts

Connect Supabase Storage

14/21

Connect Supabase and create the [table name] table with these columns: [list columns and types]. Wire the [page name] page to read from and write to this table, replacing the current mock data. Add row-level security so users can only see their own rows. Confirm the table structure before saving any data.

Moves a page from mock data to a real Supabase table with sensible security defaults.

๐Ÿ’ก

Pro tip: Always request row-level security in the same prompt, adding it later often means re-touching every query.

Add User Authentication

15/21

Add email and password authentication using Supabase Auth. Create a sign-up page, a login page, and a logout button in the nav. Protect the [list of pages] routes so only logged-in users can access them, and redirect signed-out users to the login page. Keep the existing styling.

Adds a complete auth flow with protected routes wired to Supabase.

๐Ÿ’ก

Pro tip: List exactly which routes must be protected, Lovable will not reliably guess which pages should be private.

Wire Up Stripe Payments

16/21

Add Stripe checkout for a [one-time / subscription] purchase of [product or plan] at [price]. Create a pricing page with a buy button that starts Stripe Checkout, and on successful payment mark the user as [paid/pro] in Supabase. Explain which Stripe keys I need to add and where.

Sets up a working Stripe purchase flow and updates the user's status on success.

๐Ÿ’ก

Pro tip: Ask Lovable to tell you which Stripe keys go where, the integration silently fails if the keys are not configured.

Send Transactional Emails

17/21

After a user [does an action, e.g. signs up], send them a confirmation email. Use a Supabase Edge Function to trigger the email and include [what the email should say]. Show me the function code and tell me what email provider config I need to set. Do not change any UI.

Adds a backend-triggered email without disturbing the front end.

๐Ÿ’ก

Pro tip: Keep email logic in an edge function rather than the client so your provider keys are never exposed in the browser.

Debugging & Refining

4 prompts

Describe the Bug Precisely

18/21

There is a bug: when I [exact steps to reproduce], I expect [expected result] but instead [actual result]. Investigate the cause first and explain what is going wrong before changing any code. Then fix only that issue without altering unrelated features.

Gives Lovable a reproducible report and asks for a diagnosis before a fix, which avoids shotgun edits.

๐Ÿ’ก

Pro tip: Requesting an explanation before the fix prevents Lovable from rewriting large sections to 'guess' at a problem it has not located.

Use Chat Mode to Diagnose

19/21

Switch to chat mode and explain, without editing any code, how data flows from [page A] to [page B] in this app and where the [problem area] is handled. I want to understand the current implementation before we decide on a fix.

Uses Lovable's chat (discussion) mode to understand the code without triggering edits.

๐Ÿ’ก

Pro tip: Chat mode is your safe space, use it to plan and understand before switching back to edit mode for the actual change.

Revert and Re-Approach

20/21

The last change to [feature] caused [problem]. Undo that approach and instead implement it differently: [describe the alternative approach]. Keep everything else exactly as it was before the broken change.

Cleanly redirects after a bad edit by pairing a revert intent with a concrete new plan.

๐Ÿ’ก

Pro tip: If a feature keeps breaking, use Lovable's version history to roll back to a known-good state before prompting a fresh approach.

Improve Performance

21/21

The [page name] page feels slow when [scenario, e.g. the list has many items]. Investigate what's causing the slowness first, then optimize it, for example by paginating the query, loading data lazily, or avoiding unnecessary re-renders. Keep the UI and behavior identical, only make it faster, and tell me what you changed.

Targets a real performance problem with a diagnosis-first approach while preserving the existing behavior.

๐Ÿ’ก

Pro tip: Describe the exact slow scenario rather than asking to 'make it fast', so Lovable optimizes the path that actually hurts.

Frequently Asked Questions

A good Lovable prompt is specific and scoped: it names the exact feature, the page it affects, the data involved, and the constraints (what to keep or not touch). Building one feature at a time and reusing existing components produces far cleaner results than asking for a whole app in a single message.
No. Lovable works best incrementally. Scaffold the core UI first, approve it, then add features one at a time, then connect the backend. Large all-in-one prompts tend to produce tangled code that is hard to debug and refine later.
Chat mode lets you ask questions and plan without changing your code, which is ideal for understanding the current implementation or diagnosing a bug. Edit mode actually generates and modifies code. Use chat mode to think, then switch to edit mode to build.
Lovable has native Supabase integration for the database, auth, and edge functions, and supports Stripe for payments. Prompt it to create specific tables with row-level security, add Supabase Auth with protected routes, and set up Stripe Checkout, and ask it to tell you which keys to configure and where.
Describe the bug with exact reproduction steps and the expected versus actual result, and ask Lovable to diagnose the cause before changing code. Scope the fix to the affected area and tell it not to touch unrelated features. If an edit goes wrong, use version history to revert.

Prompts are the starting line. Tutorials are the finish.

A growing library of 300+ hands-on tutorials on ChatGPT, Claude, Midjourney, and 50+ AI tools. New tutorials added every week.

7-day free trial. Cancel anytime.