Paste the full spec you wrote in the Product Spec session — scope, who it's for, core flow, pages, data, out-of-scope, risks, open questions. Every prompt below pulls from it so you don't have to re-explain your app each time.
Saved ✓
Step 1
Build your V1
The goal is one thing: get something working. Take the spec you wrote in the last session and paste it directly into Lovable. Don't rewrite it, don't summarize it — just drop it in as-is.
The goal is one thing: get something working. You already have Claude Code installed — open it, start fresh, and paste your spec in as your first message. It'll build the app file by file.
2Paste your spec directly into the prompt box and hit generate
3When it's done, click through the app. Don't touch anything yet — just look.
4Write down 3–5 observations. What's working? What's missing? What feels wrong?
Do this
1Open Claude Code (anywhere is fine — it'll make its own folder)
2Switch to Opus 4.7 — the strongest model for building. Type /model and pick claude-opus-4-7
3Copy the prompt below and paste it in. It pulls your spec from the top of the page and tells Claude Code to make a folder, scaffold the app, build it, and start the dev server.
4When Claude Code says the dev server is running, open localhost:3000 in your browser. Click through — don't touch the code yet. Write down 3–5 observations.
Paste into Claude Code
What you're looking for
Don't judge the design. Ask: does this do the core job? Can a user do the thing the spec describes? Are the main screens there?
It will be imperfect. That's the point. You now have something real to react to — which is far more useful than a blank page.
Step 2
Iterate
You will not get it right on the first build. That's not a failure — that's the process. The skill isn't building a perfect V1. It's knowing how to give good feedback and turn it into specific, actionable instructions for Lovable.
The iteration loop
Vibe coding works best in tight loops: observe → articulate → fix → repeat. The mistake most people make is trying to fix everything at once, or giving Lovable vague direction like "make it better." Specific beats comprehensive every time.
The prompt below does a two-step handoff for you: first Claude turns your raw observations into structured feedback, then it writes the Lovable prompt you need.
Before you diagnose
Things that commonly go wrong in an AI build
If any of these look familiar, you already know what to put in "what's going wrong."
1 of 5
The preview looks polished, but clicking the main button does nothing
Lovable's default output is a beautiful UI — real buttons, real layouts, real forms. What's missing is what happens when you interact. The button is there, but it's not wired to anything. The form accepts input but doesn't submit. The "Delete" button doesn't delete. First impressions make you think the app works; clicking through proves it doesn't.
Generate briefingnothing happens on click
How to catch it
Before you look at design, walk the happy path end-to-end. Click every button on the core flow. If nothing responds, the "app" is a sketch.
How to fix it
In your next prompt, name the button and the behavior: "When I click Generate briefing, the draft should appear below the input field."
2 of 5
Everything you add disappears the moment you refresh the page
When Lovable first builds your app, it often stores data in React state — memory that lives only while the tab is open. You add three items, they show up, everything feels alive. Then you hit refresh and the page is empty. Nothing was ever saved to a database.
Before refresh
Monday brief · draft
Launch checklist · v2
Roadmap notes
After refresh
No entries yet
How to catch it
After any action that adds or changes data, refresh the page. If it's gone, you don't have persistence yet — you have memory.
How to fix it
Say it explicitly: "Save each brief to the database and load them on the dashboard." Lovable uses Supabase for storage, but only when you ask for it.
3 of 5
Lovable adds features you never asked for — nav bars, settings pages, sign-up flows
AI fills ambiguity with averages. If your spec doesn't clearly state what's not in V1, you'll often get a full navigation structure, a settings page, an auth flow, a team dashboard — features pulled from generic SaaS templates. Your one-page checklist becomes a five-page product.
What your spec asked for
A one-page checklist
Task rows with checkboxes
Notes field per task
What Lovable built
Sidebar navigation
Sign-up / login
Settings page
Team management
Analytics dashboard
How to catch it
Count the pages. Read the nav. Does everything on screen trace back to something in your spec? If there's a sidebar with five items and your spec had two, you've been expanded.
How to fix it
Be explicit in the next prompt about what to remove: "Remove the sidebar, the settings page, and the sign-up flow. Keep only the checklist page."
4 of 5
The app shows fake data that looks real, but it's not tied to anything you input
To make the demo feel alive, Lovable often hardcodes plausible-looking data: "Sarah Chen — 3 tasks", "Acme Corp — last updated 2h ago". It looks like the app is working. It's a static mock. When you try to add your own entry, it may not show up, or it shows up alongside the stubbed rows that won't go away.
Sarah Chen3 tasks · updated 2h ago
Acme Corp launch12 tasks · updated yesterday
Q4 roadmap5 tasks · updated last week
Hardcoded in the UI. None of this came from you.
How to catch it
Read the names, numbers, and dates. Did you enter any of them? Do they reset to the same values on every reload? That's a stub, not your data.
How to fix it
Ask for an empty state on purpose: "Start the app with no entries. The user adds the first one." Test with your own inputs before you trust it.
5 of 5
Asking "make it better" changes five things — and none of them were the actual problem
Vague prompts get vague interpretations. "Improve the design" might redesign your layout, change your colors, and move your buttons — but leave the broken form alone. You can't predict what will change, and you can't reliably reverse it. Each round of vague asks drifts further from where you wanted to land.
Vague — unpredictable output
Make the dashboard nicer.
Specific — buildable
On the dashboard, move the New entry button above the list and make it full-width. Group entries by week. Keep everything else the same.
How to catch it
Before you hit send, ask: could someone else read this and interpret it three different ways? If yes, the output will surprise you.
How to fix it
Every ask names the page, the element, and the expected behavior. The prompt below helps you do that — it turns your rough observations into precise instructions.
Step 1 — Turn your observations into structured feedback
Fill in for this prompt
Your raw observations from the V1. One per line. Don't edit yet — specificity beats polish. Use the carousel above to jog your thinking.
An evolution of your original spec, now that you've seen V1. What should the app actually do or feel like in the next round? Describe the outcome — not the implementation.
Paste into Claude
Paste into Claude Code
After you paste into Lovable
Review what changed. Does it look closer to what you meant? Are there new problems the fix introduced? Write down a fresh set of observations and repeat the loop.
Most apps need 3–5 rounds of iteration before they feel right. That's normal.
After Claude Code finishes editing
Reload the browser. Walk the happy path again. Does it look closer to what you meant? Did the fix introduce new problems? Check what Claude Code says it changed — sometimes it'll tell you something it couldn't fully resolve.
Most apps need 3–5 rounds of iteration before they feel right. That's normal. Commit your work between rounds so you can roll back if a round goes sideways.
Step 3
Design & refine
Now that you have something working, make it feel intentional. Visual design is a lot easier to get right when the structure is already solid.
Step 1 — Define your visual style
Two ways to do this. Describing a feeling works when you have strong opinions about the vibe. Matching a reference site works when you don't — especially for work apps where you want to look on-brand without writing a brief.
Fill in for this prompt
2–3 adjectives — e.g. "calm, professional, trustworthy" or "playful, energetic, bold."
Fill in for this prompt
Paste a URL whose visual language you want to borrow — your company's marketing site, a product you admire, anything.
Claude will visit the site, infer the brand — colors, type, tone, density — and write a Lovable prompt to apply it.
Paste into Claude
Paste into Claude
Paste into Claude Code
Paste into Claude Code
Step 2 — Tighten your inputs and outputs
Fill in for this prompt
Fields, uploads, buttons they interact with — in order if possible.
Paste into Claude
Paste into Claude Code
Step 3 — Deploy
Your first deploy
Deploy
This is your first deploy — you'll redeploy at the end after making more changes.
In Lovable, click Share (or Publish depending on your version)
Follow the prompts to deploy
You'll get a URL — this is your live page
Open it on your phone to make sure it works
Your first deploy
Deploy
Your app is running locally. Time to put it on the internet. Claude Code can do most of this for you.
Ask Claude Code: "Initialize a git repo, create a new GitHub repo for this, and push my code. Then walk me through deploying to Vercel."
Sign in to vercel.com with GitHub, import the repo, and hit Deploy
You'll get a URL — this is your live page
Open it on your phone to make sure it works
Step 4
Add the intelligence layer
Now that you have a working, good-looking app, you can ask: where does AI actually belong? This is much easier to answer now than it was before you built anything.
Step 1 — Find the right place for AI
This prompt pulls your full spec from the top of the page — no inline fields needed.
Paste into Claude
Step 2 — Build the AI feature
Fill in for this prompt
Which step AI adds to, what it does, what goes in and what comes out. Paste Claude's answer from the previous step, or summarize it.
Paste into Claude(same chat)
Paste into Claude Code
Before you ship it
Test the AI feature yourself a few times with different inputs. Ask: does it actually help, or does it just add noise? The bar is not "it works" — it's "it makes the app meaningfully better."
If it doesn't clear that bar, remove it. A clean app beats a cluttered one with AI in it.
Step 3 — Redeploy
Ship your updates
Redeploy
You've made changes since you last published. Your live URL is still showing the old version. Hit Publish again in Lovable to push your updates live.
Every time you make changes you want people to see, you need to redeploy. It takes a few seconds.
Ship your updates
Redeploy
You've changed code locally. Your live URL still shows the last deployed version. Ask Claude Code: "Commit everything with a clear message and push." Vercel auto-deploys on push — give it about 30 seconds.
Every time you want people to see new changes, commit and push. That's the whole loop.