How to actually build with Lovable: interview your LLM first

Most people open Lovable, type a paragraph describing their whole idea, hit enter, and then spend the next two hours fighting whatever comes out. It half works. They patch it. It half works differently. Eventually they conclude AI builders aren't there yet.

The tool is fine. The input is the problem. A one-paragraph brief is an under-specified spec, and an under-specified spec produces an average of every website on the internet: purple gradient, rounded cards, generic hero. You didn't get a bad build - you got exactly what you asked for, which was nothing in particular.

The fix is to do the specification work somewhere else, with something that is good at asking questions, before you spend a single Lovable credit. Here's the loop I use. I've shipped several sites and a pile of internal tools with it, and on the cheapest Lovable plan it comfortably yields four to five working websites a month.

Step 1 - Turn an LLM into your interviewer

Open whatever you like - ChatGPT, Claude, Gemini. The model matters far less than the framing. You are not asking it to build anything yet. You are asking it to extract the spec that's currently sitting half-formed in your head.

You are a web developer who specialises in building sites with Lovable
(React + Tailwind + shadcn, file-based routing).

I want you to build a website for me. Here's my idea:
<one or two paragraphs - the messy version is fine>

Before you write anything, interview me. Ask me questions until you
understand:
- who this is for and what they should do after landing on it
- the pages and what lives on each one
- the content I already have vs. what needs writing
- the design direction: references I like, references I hate,
  colour, typography, mood
- anything I'd consider forbidden or off-brand

Ask them in small batches so I can actually answer. Don't start
building until you say you have enough.

The two clauses that matter most are 'small batches' and 'don't start building'. Without the first you get a wall of thirty questions and give up. Without the second the model gets excited and starts producing code at question four.

Step 2 - Do the interview honestly

This is the part people skip, and it's the part that carries the whole method. Fifteen to twenty minutes of answering questions here saves hours of re-prompting later.

Answer in your own words, badly if necessary. 'I don't know' is a legitimate answer - it tells the model to decide and to flag the decision. Where you do have an opinion, be brutally specific, especially about design. 'Modern and clean' means nothing. 'Near-white background, black 2px borders, no rounded corners, one acid-yellow accent, absolutely no gradients' means something a build can be checked against.

State your negatives too. A list of things that are forbidden is worth more than a list of things you like, because it's the only reliable defence against the model's defaults.

Step 3 - Ask for a prompt queue, not a prompt

Once the interview is done, you don't ask for the site. You ask for the sequence of instructions that will build the site.

Good, you have enough. Now write me a series of prompts I can paste
into Lovable one at a time, in order.

Rules:
- prompt 1 is design system only: colour tokens, typography, spacing,
  border and shadow rules, and an explicit forbidden list
- then layout: header, footer, routes as placeholder pages
- then one prompt per page or per major component
- each prompt must be self-contained and describe a state I can look
  at and verify
- no prompt should touch more than one area of the site
- end each prompt with what I should see when it's done

Design system first is not a stylistic preference, it's leverage. Every later prompt inherits those tokens, so you correct the visual language once instead of on every page. If you build the homepage first and then decide on the palette, you're repainting.

Small prompts are the other half. A prompt that changes one thing produces a diff you can actually judge. A prompt that changes six things produces a result where something is definitely wrong and you can't tell which instruction caused it.

Step 4 - Paste one prompt. Stop. Check.

Now the boring, effective part. Paste prompt one. Wait. Look at the preview properly - not a glance, an actual look. Ask yourself whether this is the direction, not whether it's finished.

1. Does it match the spec, or does it merely look nice? Nice-but-wrong is the expensive failure mode, because it survives another five prompts before you notice.
2. Check it at 375px wide. Responsive breakage compounds; fix it at prompt two, not prompt twelve.
3. Click every link and tab through the page with the keyboard. Broken navigation added early stays broken.
4. If something is off, fix it now, in place, before the next prompt. Never queue corrections.

The stop-and-check between prompts is the whole discipline. Drift is cheap to correct at one prompt of distance and brutal at five, because by then the wrong pattern has been copied into every component the model wrote since.

Step 5 - Publish, then iterate against something real

Publish earlier than feels comfortable. A live URL changes the questions you ask: you stop polishing a section nobody scrolls to and start fixing the thing that's actually confusing on a phone. Keep iterating in the same rhythm - one prompt, one check.

On cost: this method is why the cheapest plan is enough. Credits get burned by re-prompting, not by building. When each prompt lands close to correct because the spec was settled beforehand, four to five real, working sites a month is a comfortable pace rather than a stretch.

Going further: let the LLM design the schema too

The same loop extends to anything with a backend. Before you touch the database, have the interview again - this time about entities, relationships, and who is allowed to read or write what.

Same project. Now design the database schema.

Interview me first: what objects exist, how they relate, who owns
each row, what needs to be public vs. private.

Then give me, as separate paste-ready prompts:
1. the tables and their columns and types
2. row-level security: one policy per table, stated in plain English
3. the read/write paths the app needs

Explain each table in one sentence before the SQL.

Then paste those in order, the same way. Access rules deserve their own prompt and their own check - this is the one place where 'looks fine' is not evidence of anything. Log in as a second user and confirm you can't see the first one's data.

This is how most of my internal tools got built: a CS bandwidth tracker, a bonus management tool, a quote creator. Not consumer products, just small internal things that used to be a spreadsheet and a chase-up. Also the fastest way I know to answer 'could we just build this?' in an afternoon instead of arguing about it for a quarter.

The one rule that matters most

Take a moment and always try to understand what the AI gives you.

Read the output. Not to catch the model out - to know what you now own. Which files changed, what that component actually does, why that route exists. It takes two minutes per prompt.

Skip it and you accumulate a codebase you can't reason about, and the first real bug becomes unfixable by you at exactly the moment it matters. Do it and something better happens: you get faster. You start recognising which instructions produce clean results and which produce mush, and your prompts get sharper because you've seen what they do.

That's the actual skill here. Not prompt magic - specification, sequencing, and reading the diff. The tool just makes the loop fast.

The loop, in short

• Interview yourself through an LLM before you open Lovable.
• Answer honestly, and be specific about what is forbidden.
• Ask for a numbered queue of self-contained prompts, design system first.
• Paste one, stop, QA at 375px and with the keyboard, fix before moving on.
• Publish early and iterate in the same rhythm.
• Read what the AI gave you, every single time.