Use ChatGPT to Prompt Lovable: A Field Guide for People Who Don't Know What They're Doing

Lovable looks like a chatbot. It has a prompt box, it types back, it says things like 'I'll help you with that.' This is a trap. A chatbot understands intent; Lovable understands instructions. The gap between those two things is where your credits go to die.

When you type 'make the homepage look more professional,' you are not prompting. You are praying. You are asking a machine to read your mind, reconcile your aesthetic anxieties, and produce the thing you would have built if you knew what you were doing. Lovable will try. It will change a font, add a gradient, move a button, and then you will say 'no, not like that' and burn another prompt. This is the expensive oracle problem: every vague request is a small donation to the god of ambiguity.

There is a better way. Do your messy, vague, exploratory thinking in a cheap external LLM — ChatGPT, Claude, Gemini, whatever — and only feed Lovable the cleaned-up, specific, actionable spec. The external LLM is your thinking partner. Lovable is your builder. Keep them separate and both get cheaper.

Why an external LLM first

Lovable credits are real money. Every message costs something. Every 'can you make it a bit more...' costs something. Every error loop costs something. ChatGPT Plus is twenty dollars a month and you can have forty conversations in an hour without flinching. Claude Pro is similar. Even the free tiers are enough for drafting.

The economics are simple: you can iterate ten times in Claude for the price of one wrong attempt in Lovable. More importantly, the external LLM is patient. It will ask you clarifying questions. It will summarise your rambling. It will turn 'I want it to feel trustworthy' into 'use a navy header, a sans-serif font, a testimonial section with three quotes, and no stock photos of people in suits pointing at whiteboards.'

Lovable cannot do that exploratory work cheaply because Lovable is not a therapist. It is a compiler wearing a chat interface. Give it the spec and it will build. Give it a mood and it will guess.

Anatomy of a good Lovable prompt

A good Lovable prompt has five parts. Skip one and the result wobbles. Skip two and you are back to burning credits.

• →Context — who the user is, what the business does, what this page or feature must achieve. Lovable does not know your customer. Tell it.
• →Constraints — the stack, the design tokens, the things you do not want touched. Lovable is enthusiastic and will rewrite your entire app if you let it.
• →Specificity — exact components, fields, buttons, data flows, edge cases. 'A contact form' is a wish. 'A contact form with name, email, message, honeypot field, validation, success toast, and data stored in Supabase' is a spec.
• →Output format — what you want back. A new route? A component? A server function? A database migration? A design only? Say so.
• →Iteration instructions — how to handle errors, what not to break, whether to edit existing files or create new ones. Lovable is brave. Sometimes it needs to be told to sit down.

The LLM → Lovable workflow

Step 1: Dump your vague idea into the external LLM. Do not try to be clever. Write 'I want a landing page for my dog-walking business that makes people trust me.' Then ask the LLM to interview you: 'Ask me five questions to clarify this.' It will ask about audience, tone, must-have sections, booking flow, branding. Answer honestly.

Step 2: Ask the LLM to convert the interview into a Lovable-ready prompt using the anatomy above. Give it the template. It will produce something embarrassingly more specific than anything you would have written.

Step 3: Paste into Lovable. One feature at a time. Do not ask for the homepage, the booking system, the blog, and the admin dashboard in one message. Lovable can do a lot, but it does one thing well at a time.

Step 4: When Lovable throws an error or produces something weird, paste the error and the original prompt back into the external LLM. Ask it to diagnose. It will often spot that you asked for a table that does not exist, or a component that conflicts with your existing layout, or a dependency you did not install.

Step 5: Feed the diagnosis back into Lovable as a corrected prompt. Repeat until it works. This loop is where the magic lives. Most people skip it and blame the tool.

Worked examples

Here are three before-and-after transformations. The 'before' is what most people type. The 'after' is what the external LLM helps you produce before you touch Lovable.

Example 1 — A landing page

• →Bad: 'make a nice homepage for my dog walking business.'
• →Good: 'Create a new route at / for a dog-walking business called Hound & Found. The hero section should have a headline, a subheadline explaining same-day walks in Bristol, a primary CTA button linking to /booking, and a secondary CTA scrolling to #services. Include a three-column services section, a testimonial section with two placeholder quotes, and a newsletter signup with email field only. Use the existing design tokens. Do not add new dependencies. Do not change the navigation or footer. Create the route file and any components under src/routes/ and src/components/.'.

Example 2 — A contact form

• →Bad: 'I need a contact form.'
• →Good: 'Add a contact form to the /contact route. Fields: name (required, max 100 chars), email (required, validated), subject (dropdown: General, Booking, Feedback), message (required, textarea, max 2000 chars). On submit, validate client-side, show a loading state, then call a createServerFn named submitContactForm under src/lib/contact.functions.ts. That function inserts the submission into a Supabase table called contact_submissions with columns name, email, subject, message, created_at, and status default new. Return success or validation error to the client. Show a success toast and clear the form. Add a honeypot field to reduce spam. Do not change the page layout or styling beyond the form itself.'

Example 3 — User profiles

• →Bad: 'users should have profiles.'
• →Good: 'Create a public.profiles table in Supabase with columns id (uuid, primary key, references auth.users), full_name (text), bio (text, max 500), avatar_url (text), created_at and updated_at timestamps. Enable RLS. Create policies: users can read any profile, users can only update their own profile. Grant SELECT and UPDATE to authenticated, ALL to service_role. Create a trigger to create a profile row on auth.user creation. Then create a server function getProfile under src/lib/profiles.functions.ts that returns the current user's profile using requireSupabaseAuth. Do not modify the auth schema.'

A reusable Lovable prompt template

Here is a template you can paste into your external LLM, fill in the bracketed parts, and ask it to produce the final Lovable prompt:

• →Project: I am building [type of app/site] for [audience]. The current stack is [stack, e.g. TanStack Start, Supabase, Tailwind].
• →Goal: I need to [one-sentence description of what this specific prompt should achieve].
• →Context: [who the user is], [what the business does], [what success looks like for this feature].
• →Constraints: use existing design tokens and components where possible; do not add new npm dependencies unless I approve them; do not touch [list no-go areas: auth, pricing, existing routes, etc.].
• →Specific requirements: [component/field 1], [component/field 2], [data flow / what happens on submit / what happens on error].
• →Output: [new route / component / server function / migration / design only], [file paths if known].
• →Iteration notes: if you encounter an error, stop and ask before guessing; preserve existing functionality in [specific files]; test by [how to verify it works].

Ask the LLM: 'Turn this into a single, specific Lovable prompt.' Then paste the result.

Common failure modes

• →Vague adjectives: 'modern,' 'clean,' 'professional,' 'user-friendly,' 'intuitive.' These words mean nothing to a machine. They mean nothing to most humans. Replace them with specifics.
• →Bundling five features into one prompt. Lovable will try. It will fail in interesting ways. Split features.
• →Forgetting the no-go list. Lovable will happily refactor your entire app to make the new thing fit. Tell it what is sacred.
• →Asking Lovable to design. It can implement a design you specify. It cannot design your brand strategy. Do that thinking in the cheap LLM.
• →Not reading what changed. Lovable tells you what it did. Read it. If you do not understand it, ask the external LLM to explain it before you ask for the next thing.
• →Treating the first output as final. It never is. The first output is a draft. The second output is slightly better. The fifth output is what you actually wanted.

The real skill

The people who are winning with Lovable are not the ones with the best prompts. They are the ones with the clearest thinking. Prompting is just the surface skill. Underneath is the ability to specify exactly what you want, to know what you do not want, and to debug calmly when the machine does what you said instead of what you meant.

Lovable does not replace thinking. It accelerates it. The external LLM is the training wheels for that skill. Use it to learn how to think in specs. Then one day you will write Lovable prompts directly, and they will land the first time.

Until then, stop praying into the prompt box. Do the thinking somewhere cheap. Then tell Lovable exactly what to build.