App builders · guidance updated 4 Oct 2026
Lovable prompt guide
Lovable chooses and silently upgrades the models behind Chat, Plan and Build modes, and users cannot pick one. So write prompts that work on any model rather than tuning for a specific one.
How to prompt Lovable
- Open with what the app is for, who uses it and the main user journey before any feature list.
- Ask for one page, section or feature per prompt and build the app up component by component.
- Give a definite visual direction with concrete adjectives (minimal, premium, playful), plus colours, type and spacing.
- Use real copy and sample data, not lorem ipsum, so layouts are sized for real content.
- Name UI elements precisely (card, modal, tab bar, data table) instead of describing vague layouts.
- For multi-step or risky features, say to use Plan mode first and only build once the plan is approved.
- Set boundaries: name what may change and what must stay untouched, e.g. 'only change the orders page; leave auth and styling alone'.
- List the states to handle (loading, empty, error) and how the layout changes on mobile versus desktop.
- Name the built-in backend needs (accounts, database tables, file storage, roles) without going into implementation details.
- For embedded media or reference pages, give the URL and say where it goes, how it looks and why it is there.
- End with 'Ask me any questions you need to fully understand what I want' when the request is still loose.
- Put rules that apply on every message into Project or Workspace Knowledge instead of repeating them in prompts.
The shape of a good prompt
[Goal: what the app is and who it is for] [Core user journey: 3-5 steps] [This prompt's scope: one page or feature] [Visual style: mood, palette, type, spacing] [Structure: sections in order, navigation] [Interactions and states: hover, loading, empty, error] [Responsive: desktop vs mobile] [Data and auth needs] [Boundaries: what not to touch] [Ask clarifying questions]
Avoid
- Asking for a whole multi-page product in one prompt
- Generic descriptors like 'modern' or 'clean' with no further detail
- Placeholder text instead of real content
- Edit requests that don't say what to leave unchanged
- Pasting the same standing rules into every message instead of Knowledge
Example
Request an app for my dog walking business
Build a booking web app for a solo dog-walking business. Users: dog owners booking walks on their phones, and me (the walker) managing my schedule. Core journey: owner signs up -> adds dog profile (name, breed, notes) -> picks a 30 or 60 min slot from my availability -> gets confirmation; I see today's walks in order. Start with just the public landing page and the booking flow (no admin yet). Visual style: friendly and playful but tidy: warm off-white background, forest-green primary, rounded cards, a rounded sans-serif, generous spacing. Use real copy: headline 'Happy dogs, tired legs', 3 benefit cards, 2 pricing cards (30 min £12, 60 min £20). States: loading skeletons, an empty state when no slots are free, inline form errors. Responsive: mobile-first; booking steps stack on mobile, two columns on desktop. Data: user accounts with email login, tables for dogs, bookings, availability. Ask me any questions you need to fully understand what I want before building.