How to Prompt Lovable So It Works First Time

The difference between a Lovable prompt that works first time and one that takes six attempts is not length, and it is not clever phrasing. It is whether the prompt decides things.

Every decision you leave open is a decision the model makes on your behalf, using its defaults. Some of those defaults are fine. Most of them are the reason generated websites look alike, and every one you have to correct afterwards costs another message.

This is what we learned writing 150 prompts and generating 106 websites from them.

Why the first generation is a cost question

Lovable bills per message, not per project. A prompt that produces something usable immediately costs you one generation. A prompt that produces something nearly right costs you that generation plus every follow-up needed to fix it.

When we measured what our own websites cost, the most expensive came to 14 credits, about $3.50, and the cheapest to 1.5 credits, about 38 cents. Both were single-page marketing sites of a similar size. The gap was not ambition. It was how many corrections the first output needed.

So first-generation quality is not only an aesthetic concern. It is the main thing standing between you and a bill four times larger than it needed to be.

What a prompt has to decide

A prompt that reliably works first time settles ten things. Leave any of them out and the model fills the gap for you.

• The goal — one sentence naming the business, the place and the overall feeling.

• The stack — React, Vite, TypeScript, Tailwind. Say it rather than assume it.

• The colour system — actual values, written as CSS custom properties.

• The typography — a Google Fonts link and which face does which job.

• One or two visual effects — described precisely enough to be built.

• The sections — named, numbered and in order.

• The animations — durations, delays, and what triggers them.

• The responsive behaviour — what changes on mobile, stated per section.

• The copy — all of it, written out.

• The dependencies — a short list, or none at all.

That looks like a lot of writing. It runs to roughly ten thousand characters, and it costs almost nothing: prompt length correlates with credit cost at just +0.33 across our dataset. One 966-character prompt cost 4.10 credits. A 9,111-character prompt cost 2.00.

Write the copy, or the model will

This is the highest-impact rule on the list and the one most people skip.

If you do not supply the words, Lovable writes them, and what it writes is the tell. Empty superlatives. Invented statistics. Three-word value propositions that could belong to any company in any industry. A good layout carrying fake words reads as a template; a plain layout carrying real words reads as a business.

Write the headline, the subline, every section heading, the service descriptions and at least one testimonial in a real human voice. Leave the model the microcopy — button labels, form placeholders, alt text. It handles those fine, because in microcopy there is nothing to invent.

Give colours values, not adjectives

"Warm and modern" produces the model's defaults. A colour system produces a design.

Write the palette as CSS custom properties with real values, say what each one is for, and the whole build inherits it. Six tokens is enough: a background, a foreground, a primary, a muted foreground, a border and one accent. Write them in HSL rather than hex if you want to adjust lightness later without re-picking every colour.

The same applies to type. "Clean sans-serif" gets you the default. A Google Fonts link plus one line saying which face is used for headings, which for body and which for small uppercase labels gets you a typographic system.

Name every section, in order

Do not ask for "a homepage for a bakery". List the sections: navbar, hero, today's bakes, the sourdough process, the shop, opening hours, footer. Number them. Say what goes in each one.

Unnamed sections are where sameness creeps in. Left to itself the model produces the same eight blocks for a law firm and a tattoo studio, because those eight blocks are the average of everything it has seen. Naming them is how you get a site that belongs to one business.

Leave the component libraries out

Naming a UI library looks like a shortcut and behaves like the opposite. Every library becomes an install, a set of imports, a wiring step and a type contract, and when any part of that fails you pay a message to fix it.

In our data, every project above 7 credits combined a third-party UI component with a value that recomputes as the user changes an input. The four cheapest projects used neither.

Native HTML covers most of what those libraries were doing. A date input, a range input and a details element need no installation and cannot fail at the integration step, because there is no integration step.

What did not work

Three things we tried and would not repeat, stated plainly because most prompting advice only lists the wins.

Shortening the prompt to save credits. We measured this properly and it does not work. Length is close to free, and cutting it costs you exactly the specificity that makes the output good.

Pasting in implementation code. We include short code examples for visual effects and we cannot prove they help. Code blocks correlate with credit cost at +0.27, so they are not free, and Lovable frequently rewrites the implementation anyway. Describing the effect in two sentences may be all that is needed. We are still testing this one.

Asking for a mood instead of a specification. "Make it feel premium" and "something modern and clean" produce the defaults every time. If you cannot express it as a value, a font, a section or a sentence of copy, the model cannot build it.

The same brief, written twice

Here is a brief written the way most people write them:

Create a modern, professional website for a bakery. It should look clean and welcoming, with nice photos and a menu section. Make it mobile friendly.

Every noun in that sentence is a decision handed to the model. Modern how. Professional to whom. Which sections, in what order, with what words in them.

The same brief, decided:

Build a website for Flour & Ash, a sourdough bakery in Leeds. Background hsl(38, 30%, 96%), text hsl(24, 16%, 14%), one burnt-orange accent at hsl(18, 62%, 48%). Headings in Fraunces 600, body in Inter 300. Seven sections in this order: navbar, full-bleed hero with the headline "Bread that takes two days, because it has to", today's bakes as four items with prices, the two-day process in three steps, a photo strip, opening hours and address, footer. Hero image: a cut sourdough loaf on a floured wooden board, warm morning light, shallow depth of field.

The second is four times longer and costs the same to run. The difference is that nothing in it is left for the model to guess.

A skeleton to copy

Use this order every time. It is the structure behind all 150 prompts in our library.

• 1. Goal — one sentence: what, for whom, and what it should feel like.

• 2. Stack — React, Vite, TypeScript, Tailwind, plus any animation library.

• 3. Colours — six CSS custom properties with real values.

• 4. Typography — the font link plus one line per role.

• 5. Visual effects — one or two, described precisely.

• 6. Sections — numbered, named, with the content of each.

• 7. Animations — durations, delays, triggers.

• 8. Responsive — what changes at tablet and mobile.

• 9. Copy — every word, written out.

• 10. Dependencies — as few as possible, ideally none beyond the stack.

Write it once for a business type and the skeleton is reusable. Sections one, two, four, five, seven, eight and ten carry over between industries almost unchanged. Only three, six and nine — colours, sections and copy — genuinely need rewriting each time.

That is the whole trick. Not a magic phrase, not a jailbreak, not a longer prompt. Just deciding, in advance, everything you would otherwise have spent five follow-up messages correcting.