The engineering-first guide to prompting in Lovable
You get better results in Lovable by describing a user's journey rather than a screen, changing one thing per prompt, and settling your data shape before you build on top of it.
This is a sample entry. The structure is final; the full write-up is on its way.
A weak prompt describes a screen. A strong prompt describes a person trying to do something, the steps it takes, and what success looks like at the end.
What should a first prompt include?
- Who the product is for, and what they are trying to finish.
- The main screens, named in the order the user meets them.
- What the user can do on each one.
- The tone and feel you want, with a reference you actually like.
- Anything that must be true: sign-in, roles, data that has to persist.
Why does one change per prompt work better?
Large prompts produce large diffs, and large diffs are hard to judge. A sequence of small, clear changes is faster overall because you can tell immediately which one was wrong.
Common questions
Is a longer prompt always a better prompt?
No. Specific beats long. A short prompt naming the user, the journey and the constraint outperforms a page of adjectives.
More on this: Lovable mastery & prompting
Built something in Lovable you want people to rely on?
We are the engineers who take it the rest of the way — secured, tested, released and supported.