Prompting in Lovable

The quality of what Lovable builds depends heavily on the quality of your prompt. A vague instruction produces a vague first version; a sharp, specific prompt often produces something usable on the first try. This guide shows how to structure, iterate and debug your prompts.

New to Lovable? Start for free with Lovable and try the examples below in your own project right away.

The anatomy of a good prompt

A prompt that works well usually includes these elements:

Element	Why it helps
Goal	What should this piece do?
Audience	Who is this for, and what do they already know?
Data	What data goes in, static or from the database?
States	What do empty/loading/error/success look like?
Edge cases	What happens with very long text, no results, no internet?
Design direction	Style, colors, references to existing components

The more of these elements you fill in, the fewer correction rounds you'll need.

Example prompts: short vs. long

A short prompt works fine for small, clear changes:

Add a "back to top" button that appears once someone scrolls
more than 400px down the page.

For something bigger, a more detailed prompt pays off. Compare:

Before (too vague):

Make a contact page.

After (specific):

Build a contact page with:
- A form with name, email, phone (optional) and message
- Validation: name and email required, email must be a valid format
- A success message after submitting, and a clear error message
  if sending fails
- On desktop, a block on the right with address details and a map
- Style: match the existing "About us" page, use the same buttons
  and colors

The second prompt almost always produces a more usable result, because states (success/error) and design direction are already defined.

Iterating in small steps

Don't ask for everything at once. Build up:

Step 1: Build the basic form with fields for name, email and message.

Check the preview, then continue:

Step 2: Add validation: name and email required, email must be
a valid format. Show error messages below the field itself.

And only then:

Step 3: Add a success and error message after submitting, and make
the form read-only while it's being submitted.

This keeps each error small and easy to trace, and lets you roll back precisely if needed.

Referencing existing components

Lovable builds more consistently if you reference what already exists, instead of describing what something should look like every time:

Use the same card component as on the homepage for the team
members page, but show name, role and photo instead of title
and description.

This prevents a sprawl of slightly-different buttons, cards and forms across your project.

Debugging via the error message and console

If something breaks, don't just say "it doesn't work." Copy the exact error message from the console or network tab:

The page crashes with this console error:
"TypeError: Cannot read properties of undefined (reading 'map')"
on the product overview page. Fix this and make sure the page
shows a proper empty state if there are no products.

An exact error message plus context (which page, which action) almost always gets you a correct fix faster than a general complaint.

Prompts for SEO, performance and accessibility

These topics are often forgotten, but are easy to prompt for if you're specific:

Check that every page has a unique title and meta description.
Add missing alt text to images based on the context of the page.

This page loads slowly because of a large hero image. Optimize
loading (e.g. lazy loading for below-the-fold content) without
changing the layout.

Check the contact page for accessibility: labels on form fields,
visible focus states on interactive elements, and sufficient
color contrast between text and background.

What you shouldn't try to solve with a prompt

Not everything belongs in a prompt. Be cautious with:

• Security-critical authorization logic — have a human review RLS rules and who can access what data, especially for sensitive information.
• Complex architectural decisions — use plan mode and think along yourself, rather than trusting that one prompt will pick the right structure.
• Legal or compliance text — a prompt can draft a concept, but always have privacy policies and terms checked by an expert.
• Pricing calculations with complex business rules — describe the rules precisely, and test the outcome yourself; don't blindly trust generated logic.
• One giant mega-prompt — large, vague requests lead to results you'll end up correcting piece by piece anyway.

A reusable prompt template

Use this template as a starting point for new features:

Goal: [what should this component do]
Audience: [who is this for]
Location: [which page/where in the app]

Data:
- [what data, static or from the database]

States:
- Empty: [what you see when there's no data]
- Loading: [what loading looks like]
- Error: [what you see on error]
- Success: [what you see on success]

Edge cases:
- [e.g. very long text, no internet, extremely many results]

Design direction:
- [reference existing pages/components, or describe the style]

Fill this in and paste it as a prompt: it will save you several correction rounds.

What we recommend

Start small, check every step in the preview, and use plan mode once a change touches multiple pages or the data model. Combine that with specific, error-message-driven debug prompts, and always have a human review sensitive logic (authorization, payments). Want help setting up a prompting workflow for your team? Check web design or get in touch.

Frequently asked questions

How long should a prompt be?

As long as needed to make the goal, data, states and edge cases clear — often a few sentences to a short list, not necessarily a long essay.

Can I edit an earlier prompt instead of writing a new one?

No, you steer with a new instruction in the chat. Use rollback to an earlier version if a step went the wrong way.

Does prompting in English work better than in Dutch?

Both work; use the language you can phrase most precisely in. Consistency within one project does help though.

What if Lovable keeps getting something wrong after several attempts?

Give the exact error message, describe what you've already tried, and consider breaking the problem into a smaller step. If it stays tricky, that's a good moment to have a developer look at it via web design.