30 Best Lovable Prompts (2026)

Fill in and save this as my project Knowledge file. Keep it concise — it will be sent with every prompt.

Product: [one-line description of what the app does]
Problem it solves: [the core pain]
Target users / personas: [persona 1 + goal], [persona 2 + goal]
Must-have features (v1): [feature], [feature], [feature]
Out of scope for v1: [thing], [thing]
Design system: primary color [#hex], accent [#hex], font [Inter], spacing scale [4/8/16/24/32], style [clean, minimal, rounded corners, soft shadows]
Roles & permissions: [role -> what they can do], [role -> what they can do]
Tech: React + Tailwind frontend, Lovable Cloud (Supabase) backend.

Do not build anything yet. Just confirm the Knowledge file is saved.

Switch to Chat mode. Do not edit any code.

Based on my Knowledge file, write a short product requirements document for v1 of [app name]. Include: goals and non-goals, a numbered list of user stories in the form "As a [role], I want [action] so that [outcome]", the core data model (entities and their key fields), a list of screens, and acceptance criteria for the 3 most important features.

Ask me up to 5 clarifying questions first if anything is ambiguous.

Stay in Chat mode — planning only, no code changes.

Turn the PRD into a build plan I can execute one prompt at a time. Break it into ordered milestones: (1) static frontend and layout, (2) each screen with mock data, (3) backend schema, (4) auth, (5) wiring data, (6) polish and ship. For each milestone give me the exact scoped prompt I should paste in Build mode. Keep each prompt to one task.

Set up the design system for this project and apply it globally via Tailwind config and reusable UI components. Do not build feature screens yet.

Colors: primary [#4F46E5], primary-hover [#4338CA], accent [#10B981], background [#FFFFFF], surface [#F8FAFC], text [#0F172A], muted text [#64748B], border [#E2E8F0].
Typography: Inter; headings bold, body regular; clear type scale.
Spacing: 4 / 8 / 16 / 24 / 32 / 48 px.
Radius: 12px on cards, 8px on inputs and buttons. Soft shadows.
Deliver reusable Button (primary/secondary/ghost), Card, Input, and Badge components using these tokens.

Build the frontend of a SaaS MVP called [name]. Use mock data only — no backend yet.

Goal: [what the product does in one sentence].
Users: signed-out visitors and logged-in members.
Screens: marketing landing page (hero, features, pricing, footer), a sign-up / login screen (UI only for now), an authenticated app shell with a left sidebar (Dashboard, [Feature], Settings) and a top bar with user menu, and a Dashboard with 3 KPI cards plus a recent-activity list.
Data (mock): a User { id, name, email, plan } and [MainEntity] { id, title, status, createdAt }.
Follow my design system. Make it responsive. Keep components reusable.

Build a task tracker app frontend with full CRUD, using local mock state (no backend yet).

Data: Task { id, title, description, status (todo | in-progress | done), priority (low | med | high), dueDate }.
Screens: a board view with three columns (To do, In progress, Done) and drag-to-move, plus a list view with a table.
Actions: create a task via a modal form, edit inline or in the modal, delete with confirm, and change status by dragging or a dropdown.
Include filters by priority and a search box on title. Empty state when there are no tasks. Follow my design system and make it responsive.

Build the frontend of a two-sided marketplace called [name] with mock data. No backend yet.

Sides: Providers who list [service/product], and Buyers who browse and book/buy.
Buyer screens: a search/browse page with filter sidebar (category, price, rating), a listing detail page, and a "my orders" page.
Provider screens: a dashboard showing their listings and incoming orders, and a create/edit listing form.
Data (mock): Listing { id, title, description, price, category, rating, providerId, images[] }, Order { id, listingId, buyerId, status }.
Add a role switcher in the header for now so I can preview both sides. Follow my design system, responsive.

Build an internal admin tool frontend for [company/team] to manage [entity, e.g. customers]. Mock data for now.

Layout: left sidebar (Overview, [Entity], Team, Settings), top bar with search and admin avatar.
Overview: KPI cards for total [entity], new this week, and open issues.
[Entity] page: a data table with columns [name, email, status, plan, createdAt], row click opens a detail drawer with edit fields and an activity log.
Include bulk actions (export CSV, change status) and a "create [entity]" modal. Keep it dense and fast, follow my design system, responsive down to tablet.

Build a booking / appointments app frontend with mock data. No backend yet.

Goal: let clients book time slots with [provider type, e.g. a barber].
Client flow: pick a service, pick a provider, see a calendar with available slots, choose a slot, enter name/email, confirm — then a confirmation screen.
Provider flow: a schedule view (day/week) showing booked appointments, and a form to set availability and services.
Data (mock): Service { id, name, durationMin, price }, Appointment { id, serviceId, providerId, clientName, clientEmail, start, status }.
Prevent double-booking in the UI. Follow my design system, responsive.

Build a directory / listing site frontend for [niche, e.g. local coffee shops]. Mock data only.

Screens: a home page with search and category chips, a results grid of cards (image, name, category, rating, short blurb) with a filter sidebar (category, rating, price, tags), and a detail page with gallery, description, hours, map placeholder, and reviews.
Data (mock): Place { id, name, category, rating, priceLevel, tags[], images[], description, hours }.
Add pagination or infinite scroll on the results grid, and an empty state for no matches. SEO-friendly headings. Follow my design system, responsive.

Build a high-converting SaaS landing page for [product]. One page, responsive, using my design system.

Sections in order: sticky nav with logo + links + "Get started" button; hero with headline "[value prop]", subhead, primary and secondary CTA, and a product screenshot placeholder; a logo cloud ("trusted by"); a 3-column features section with icon + title + one-line benefit each; a "how it works" 3-step row; a pricing preview with 3 tiers; an FAQ accordion; and a footer with links.
Write realistic placeholder copy that sells the benefit, not the feature. Smooth scroll to sections from the nav.

Build a coming-soon / waitlist page for [product]. Single screen, responsive, my design system.

Center a bold headline "[teaser]", a one-line subhead, and an email capture form (email input + "Join the waitlist" button) with inline validation and a success state that says "You're on the list." Add a small social-proof line ("[N] people already waiting") and links to Twitter/X and a contact email in the footer. Use mock state to store the email for now — I'll connect it to the backend later. Add a subtle animated gradient background.

Build a pricing page with a monthly/annual toggle, responsive, using my design system.

Three tiers: Free ([features], $0), Pro ([features], $[X]/mo or $[Y]/yr), and Business ([features], $[X]/mo or $[Y]/yr). When the toggle switches to annual, show the discounted per-month price and a "save [Z]%" badge. Mark Pro as "Most popular" with a highlighted card. Each tier has a bullet list of included features (checkmarks) and a CTA button. Add a short FAQ below and a "contact sales" link. Keep the highlighted card visually distinct.

Add a testimonials section and an FAQ section to my landing page. Do not change any existing sections — only add these two above the footer.

Testimonials: a responsive grid of 6 cards, each with avatar placeholder, name, role/company, a star rating, and a short quote. Add a subtle hover lift.
FAQ: an accordion with 8 questions, only one open at a time, smooth expand/collapse, and accessible (keyboard + aria).
Use my design system and realistic placeholder copy.

Build an analytics dashboard screen using mock data and a charting library (recharts is fine).

Top row: 4 KPI cards (Revenue, Active users, Conversion rate, Churn) each showing the value, a small trend sparkline, and a % change vs last period with green/red coloring.
Charts: a line chart of revenue over the last 12 months, a bar chart of signups by week, and a donut of traffic by source.
Add a date-range selector (7d / 30d / 90d) that updates the mock data. Responsive grid that stacks on mobile. Follow my design system, include loading skeletons for each card and chart.

Build a reusable data table component and a page that uses it with mock data.

Columns: [name, email, status (badge), plan, createdAt]. Features: a search box that filters across name and email, click-to-sort on every column (asc/desc with an arrow indicator), a status filter dropdown, row selection with checkboxes, bulk "export selected", and pagination (10/25/50 per page) with a total count.
Include a loading state, an empty state, and sticky header. Make the component accept columns and data as props so I can reuse it. Follow my design system, responsive with horizontal scroll on mobile.

Build an admin panel layout that wraps my authenticated pages.

Left sidebar: collapsible, with logo at top, nav items (Dashboard, Users, [Entity], Reports, Settings) each with an icon and active-state highlight, and a user block at the bottom (avatar, name, sign-out).
Top bar: page title, global search, notifications bell, and avatar menu.
Content area renders the routed page. The sidebar collapses to icons on tablet and becomes a slide-over drawer on mobile. Follow my design system. Set up routing so each nav item goes to its own page (placeholder content for now).

Build a settings page with tabbed sections, using mock data.

Tabs: Profile (name, email, avatar upload placeholder, bio), Account (change password fields, delete account with a confirm dialog), Notifications (toggle switches for email/product/marketing), and Billing (current plan, payment method placeholder, invoice list, "upgrade" button).
Each section has its own "Save changes" button that shows a saving state and a success toast. Validate required fields inline. Follow my design system, responsive — tabs become a stacked menu on mobile.

Enable Lovable Cloud (Supabase) for this project and create the database schema for my app.

Tables:
- profiles (id references auth user, full_name, avatar_url, role, created_at)
- [entity] (id, owner_id references profiles, [field], [field], status, created_at, updated_at)
- [related_entity] ([entity]_id references [entity], [field], created_at)
Add sensible types, primary keys, foreign keys, and indexes on the columns I filter and sort by. Add an updated_at trigger. Do NOT wire the frontend to this data yet — just create the schema and show me the final table definitions to confirm.

Add authentication using Lovable Cloud (Supabase Auth).

Methods: email + password, and Google sign-in. On sign-up, automatically create a matching row in the profiles table.
Build a polished login and sign-up screen (my design system), with inline error messages for wrong password, taken email, etc.
Protect all app routes: signed-out users are redirected to /login; signed-in users hitting /login go to /dashboard. Show the logged-in user's name and avatar in the top bar, with a working sign-out. Keep the marketing pages public.

Enable Row Level Security on all tables and write policies. Explain each policy in one line as you add it.

Rules:
- profiles: a user can read their own profile and update only their own; admins (role = 'admin') can read all.
- [entity]: owners (owner_id = auth.uid()) can read, insert, update, and delete their own rows. Admins can read and update all. No one else can access.
- [related_entity]: access follows the parent [entity]'s ownership.
After adding the policies, list a quick test matrix showing what each role can and cannot do, so I can verify.

Add image upload backed by Lovable Cloud (Supabase Storage).

Create a storage bucket named [avatars] with policies so a user can upload and overwrite only their own files, and files are publicly readable.
In the profile settings, replace the avatar placeholder with a real uploader: drag-and-drop or click to select, client-side validation (images only, max 2MB), an upload progress indicator, image preview, and save the public URL to profiles.avatar_url. Show the new avatar in the top bar immediately. Handle upload errors with a clear message. Keep everything else the same.

Add Stripe checkout for my Pro plan using a Lovable Cloud edge function. I'll add my Stripe secret key as a secret.

When a user clicks "Upgrade to Pro" on the billing tab, call a secure edge function that creates a Stripe Checkout Session and redirects them to Stripe. On success, redirect back to /billing?success=true and show a success toast. Add a webhook (edge function) that listens for checkout.session.completed and updates the user's profiles.plan to 'pro'. Never expose the Stripe secret key on the client. Show me exactly which secret name to set.

Integrate the [external API name] API. The API key must live as a Lovable Cloud secret and only be used server-side in an edge function — never in the frontend.

Create an edge function that takes [input, e.g. a query], calls [API endpoint], and returns [the fields I need]. On the frontend, add [the UI, e.g. a search box] that calls this edge function and renders the results with loading and error states. Cache identical requests for 5 minutes to save API calls. Tell me the exact secret name to add, and show me the edge function code.

I'm getting this error. Switch to Chat mode first, diagnose the root cause, and explain it before changing anything.

What I did: [the exact steps to reproduce].
What I expected: [expected behavior].
What happened: [what actually happened].
Error message / console output:
[paste the full error and stack trace here]

Once you've explained the likely cause, propose the smallest fix. Then, only after I approve, switch to Build mode and apply just that fix — don't refactor unrelated code.

Make one change only: [describe the single change, e.g. change the primary button color to #10B981 and its hover to #059669].

Do not change any other component, layout, spacing, copy, or logic. Do not refactor. Do not "improve" anything nearby. If making this change cleanly requires touching something else, stop and tell me first instead of proceeding. Keep everything else exactly the same.

Make the entire app fully responsive across mobile (360px), tablet (768px), and desktop (1280px). Do not change any copy, colors, or features — layout and spacing only.

Fix: the sidebar should collapse to a bottom nav or slide-over drawer on mobile; tables should scroll horizontally or become stacked cards; multi-column grids should stack; the top bar should condense; touch targets should be at least 44px; and no element should overflow the viewport. Go screen by screen and tell me what you changed for each breakpoint.

Audit every screen that loads data and add the three missing states. Do not change happy-path layouts.

For each data view add: a loading state (skeletons that match the final layout, not a spinner), an empty state (friendly message, illustration or icon, and a clear CTA where relevant), and an error state (what went wrong in plain language plus a "Try again" button that refetches). Also disable submit buttons and show a spinner while a form is saving. List every screen you updated.

Connect this project to GitHub with two-way sync, then do a light cleanup pass without changing behavior.

Cleanup: remove unused files, components, and imports; delete leftover mock data that's no longer used now that the backend is wired; ensure no secrets or API keys are hardcoded anywhere in the frontend; and confirm environment/secret usage is correct. Do not rename public routes or change any feature. Give me a short summary of what was removed and confirm the repo is synced.

Prepare this app to ship and walk me through publishing.

First, in Chat mode, run a pre-launch review: confirm RLS is enabled on every table with correct policies, no secrets are exposed on the client, all forms validate input, auth redirects work, and there are no obvious console errors. List anything risky.
Then tell me the exact steps to publish and connect my custom domain [example.com], including any DNS records I need to add.
Note: my app handles [type of data] — flag whether I should get an independent security review before launch.