Lovable Cheat Sheet 🚀

Everything you need to build real web apps with Lovable — even if you've never coded before.

Living document — updated after every workshop.

---

Contents

• Part 1 — How to write a good prompt
  • The 5-step formula · The universal meta-prompt · Golden rules
• Part 2 — The most important Lovable features
  • Free Credits Activation (CBD Special) · Sharing & Team Members · Version History · Supabase · Feature table
• Part 3 — What Lovable is NOT good at
• Part 4 — The most common pitfalls
• Part 5 — When things break: The Test & Debug Loop
  • The 5 bug categories · The 4-step loop · Anti-patterns · Detailed bug-report templates
• Part 6 — The workflow that always works
• Part 7 — Insights from real workshops

---

Part 1 — How to write a good prompt

Every AI tool (Lovable, Gemini, ChatGPT, Claude) becomes dramatically better when you give it 5 things. Always in this order:

1. Tell the AI what it is (Role)

"You are an experienced product designer." "You are a senior frontend developer."

Why: The AI adapts tone, level of detail, and assumptions to the role.

2. Tell the AI what it should help you with (Task)

"Help me build a web app in Lovable." "Help me write a prompt for a no-code tool."

3. Tell the AI what the goal is (Outcome)

"At the end I want a copy-paste-ready prompt I can drop into Lovable."

4. Tell the AI to ask clarifying questions

"Before you start, ask me clarifying questions until you really understand what I want."

Why this matters: AIs love to guess. When they guess, you end up with something generic. Clarifying questions force them to be precise — and force you to be precise too.

5. Then, and only then: details

After the first 4 points are in place, add details, context, and examples.

---

The one prompt you can always use

Copy this prompt into Gemini, ChatGPT, or Claude. Let it interview you. At the end you'll get a perfect Lovable prompt:

You are a senior product and design consultant. Your client is a beginner with little to no technical or design experience who is taking a course on using Lovable — an AI tool that builds websites and web apps from text descriptions. Your job is to interview them for about 5 minutes and then write a high-quality, copy-paste-ready Lovable prompt on their behalf. The quality of Lovable's output depends almost entirely on the quality of the input prompt. Your goal is to produce a prompt that gives Lovable enough structure to build something functional AND enough design specificity to avoid generic "AI slop" output (purple gradients, rounded-2xl everything, glassmorphism, generic hero sections with two CTAs, Inter font everywhere, emoji bullets, stock-feeling layouts). ## How you work - Conduct a focused interview, not a form. Ask 2–3 questions per turn, batched logically. Aim to finish in 3–4 turns (~5 minutes total). - Treat the person with patience and zero condescension. Translate every technical term in the same sentence you use it. - **Always propose options rather than asking open-ended questions.** Beginners pick better than they describe. If they say "modern design," don't ask "what does modern mean to you?" — give them 3 concrete named references to choose between. - If an answer is vague, do not accept it. Offer choices until you get something specific. - Don't lecture about prompt engineering. Just interview and deliver. ## What you must extract before writing the prompt You will not write the final Lovable prompt until you have clear answers to all of these: **Structural / functional (so Lovable builds the right thing):** 1. What it is — a one-sentence description of the project 2. Who it's for — a specific audience, not "everyone" 3. What users can do on it — the 3–5 most important user actions 4. Pages or sections needed 5. Anything special — login, payments, integrations, data storage (if unsure, you decide what's appropriate and tell them why) **Design (so the result doesn't look like AI slop):** 6. Visual direction — propose 3 specific, named references and have them pick. Examples to draw from: editorial like The New Yorker, brutalist like Gumroad or Are.na, soft and friendly like Duolingo, sharp and technical like Linear, warm and analog like Mailchimp's older work, minimal like Apple, playful like Stripe Press, dense like Bloomberg Terminal. Pick references that fit their project. 7. Color direction — propose 2–3 specific palettes (e.g., "off-white background with a single saturated accent like deep red," "warm cream with forest green and a hand-drawn feel," "near-black with a single neon accent"). Avoid suggesting purple or blue gradients. 8. Typography feel — propose 2–3 directions (e.g., "serif headlines with a mono sans for UI," "all sans, geometric, tight tracking," "editorial mix with a display serif"). Avoid defaulting to Inter. 9. Layout density and personality — propose options (e.g., "spacious and editorial," "dense and information-rich," "asymmetric and unconventional," "grid-based and architectural"). Track what you still need. Don't move on until each item has a usable answer. ## Final output Once everything is answered, write the Lovable prompt. The site should be built on top of Lovable Cloud. Output it in a single fenced code block so the user can copy-paste it directly into Lovable.

Tip: Save this prompt somewhere handy. You'll use it often.

---

Golden rules for prompting in Lovable itself

✅ Small and targeted beats big and vague. "Make this button red" works. "Improve the design" doesn't.

✅ English works better than other languages. Even if your app should be in German/Czech/etc. — write the prompts in English.

✅ If something doesn't work: rephrase, don't write "fix the bug".

✅ Prefer Select & Edit (clicking on an element) over chat prompts — more precise and faster.

❌ Never start over from scratch — almost always better to fix step by step.

---

Part 2 — The most important Lovable features

1. Free Credits Activation — Cross Border Dialogue Special

Lovable Free only gives you 5 messages per day. That's not enough for the hackathon.

Good news: Cross Border Dialogue 2026 has partnered with Lovable's Community Team. All participants get free access to Lovable Pro Plan 1 for the duration of the event:

• 100 credits ($25 value)
• All Pro features unlocked
• The code must be redeemed before the end of the event
• The code should be shared only within the event — please don't pass it on externally

How to activate Pro Plan 1 for free:

1. Go to https://lovable.dev
2. If you don't have an account yet: click "Get started" → create an account
3. If you already have an account: go to Settings → Plans & Credits
4. Select Pro Plan 1 (100 credits) — important: monthly plan, not yearly!
5. At checkout: enter the discount code → ask your facilitation team for the current code
6. If you already have a paid account: create a new workspace to redeem the code there

⚠️ Important note about payment:

• You may be asked to enter credit card details — don't worry, you won't be charged
• You have one month to cancel before the subscription auto-renews
• 💡 Recommendation: Cancel your subscription right after activation — it stays active for the current period but won't auto-renew, so you don't have to remember later

2. Sharing your project & working as a team

One click on Publish gives you a real URL (e.g. my-app.lovable.app). You can send this to anyone — even people without a Lovable account.

Inviting team members (collaborators):

1. In your project, top right → Share or Workspace Settings
2. Choose Invite collaborators / Add team members
3. Enter your team member's email address
4. They get an invitation and can then work on your project together with you — prompt, edit, see what's happening

⚠️ Important in the hackathon context: Lovable is not built for real-time co-editing like Google Docs. If two people prompt at the same time, things get chaotic. Better: one person prompts, others watch and call out what comes next — like pair programming.

Other ways to share:

• Public projects: On the Free plan, all projects are publicly shareable via link
• GitHub Sync: You can connect your Lovable project to a GitHub repository → others can see the code, comment, develop locally
• Remix: From Lovable's Discover tab, you can use other people's projects as templates
• Change Account: By Remixing a project, you can also move it from your team-members to your own account to fully utilize everyones credits.

3. Version History — going back to an earlier version

This is your most important safety feature. If you've broken something with a prompt, you do not have to start over.

How it works:

1. In the Lovable editor, top → Version History (or the clock icon)
2. You see a list of all states — every prompt creates a new state
3. Click on an earlier state → preview
4. Restore → that state becomes active again (the later history stays preserved, you can also go forward again)

When to use:

• ✅ The last prompt destroyed something that was working
• ✅ You've made 3+ follow-up prompts and things are getting worse
• ✅ Lovable accidentally deleted whole components
• ✅ You want to compare two different designs

Rule of thumb: If you've been fixing for 5 min and it's getting worse instead of better → roll back and re-prompt.

4. Lovable Cloud — for database, login, and AI

Lovable on its own builds the frontend (the visual part). For real data, user logins, and persistence, you need Lovable Cloud.

How to do it:

1. Click the Cloud Icon in Lovable (top left) and "Enable more features" (You can also enable these features from the chat, but this view gives you more details)
2. Lovable connects automatically
3. From now on you can simply prompt Lovable:
   • "Add a login page with email and password"
   • "Save user feedback to a database"
   • "Create a table for products with name, price, image"

On the Lovable Cloud Page you can also enable AI within your app, User Management, and many other advanced functions.

In the hackathon context: Lovable Cloud is existencial if you need persistent data (user accounts, saving inputs across sessions, transfaring data between different users of the app) or want AI Integration. For pure demo apps, that don't need storage or user management between diffrent people/sessions/devices, this might not be necessary.

5. Other important features

---

Part 3 — What Lovable is NOT good at

Important to know so you don't run into traps during the hackathon:

❌ Highly complex multi-user workflows with real real-time sync — possible, but time-consuming

❌ Very specific designs from nothing — give it concrete references and inspirations, not "creative design". Otherwise you'll get standard AI aesthetics.

❌ Accurate business logic with many edge cases — Lovable builds mockups that demonstrate the concept, not polished production logic with all the special cases

❌ Real database persistence without Supabase — stays in demo mode, data disappears on reload

→ In the hackathon: Lovable is perfect for prototypes that demonstrate the concept. It is not a tool to build a finished production app in 2 days.

---

Part 4 — The most common pitfalls

---

Part 5 — When things break: The Test & Debug Loop

Most important reality check: Your first Lovable build will never be perfect. Guaranteed. The question isn't if something is broken, but how fast you find it and fix it.

The 5 bug categories — what you'll likely find

---

The 4-step debug loop

When something is wrong, NEVER prompt again right away. First run this loop:

1. CLICK — Walk through your app like a real user. Press every button. Fill every form. At least 2 min. ↓ 2. NOTE — List on paper or in a notes app (NOT in the Lovable chat): - What works? - What's broken? - What looks wrong? ↓ 3. PRIORITIZE — What MUST work for the pitch? Ignore the rest. Tackle max 3 problems. ↓ 4. FIX — Decide per problem: • Visual or small → Select & Edit • Functional or logic → describe the bug concretely in chat • Completely destroyed → Version History → Rollback

---

Anti-patterns — how NOT to debug

❌ "Make it better" / "Fix it" Lovable has no idea what "better" means to you. → Instead, describe concretely what's happening and what should happen.

❌ Don't describe the bug — re-request the feature You write "Add a quiz with questions" — but the quiz was already there, just broken. Lovable rebuilds everything with new bugs. → Describe the bug instead.

❌ Don't test, just look You scroll through, "looks good" → during the pitch someone clicks → embarrassing bug obvious. → Actually click through.

❌ Restart from scratch on error 30 sec before the pitch: "This doesn't work, I'll start over" → catastrophe. → Better a broken build with a working core than a blank reset.

❌ Believe Lovable's self-report Lovable writes: "I've added authentication." → Doesn't mean it works. → Test it yourself.

---

Prompt templates for good bug reports

The most important rule: Describe the error in as much detail as you would explain to a colleague over the phone — someone who can't open the app themselves.

A good bug report always contains three things:

1. WHAT you're doing — what exact action triggers the problem?
2. WHAT happens — what do you actually see on the screen? (incl. error messages, console errors, blank pages)
3. WHAT should happen — what would be the expected behavior?

---

❌ Bad bug reports (Lovable can do NOTHING with these):

• "It doesn't work."
• "Fix the bug."
• "The button is broken."
• "Make it better."
• "The quiz is wrong."

✅ Good bug reports — copy these templates:

When a button does nothing:

"When I click the [Submit] button on the [home page], nothing happens — no visual feedback, no navigation, nothing in the console. It should [save the entry to the list below the form and clear the input fields]."

When the logic is wrong:

"The quiz currently shows 'correct' for every answer, even when I select the wrong option. It should only show 'correct' when the user's selected answer matches the [correct_answer field] for that question. Example: question 1's correct answer is 'B', but selecting 'A' or 'C' also shows 'correct'."

When the layout is broken:

"On mobile screen sizes (under 600px), the [navigation menu] overlaps with the [hero text] in the top-right corner. The hamburger icon also extends past the right edge of the screen. Make the navigation collapse into a hamburger menu on mobile, with the icon properly positioned within the screen bounds."

When something broke after a change:

"The login form was working 5 minutes ago. After your last change to the styling, the submit button is now visually disabled (grey, no hover state) and clicking it does nothing. Please make it active again — keep the new styling but restore the click behavior."

When a console error appears:

"After clicking 'Generate Pitch' I see this error in the console: 'TypeError: Cannot read properties of undefined (reading map)'. The pitch should appear below the button — instead the area stays empty."

When something looks visually wrong:

"The price text on the product card is currently white on a white background — invisible. Make it dark grey (#333) so it's readable. The price is in the top-right corner of each card."

---

Pro tips for even better bug reports:

🔍 Be specific about WHERE: "on the home page" / "in the 2nd card from the left" / "in the header of the detail page" — not "somewhere in the app"

🔍 Name the element: "the blue Submit button" is better than "the button"

🔍 If you see a console error message, copy it verbatim (browser devtools, F12 → Console tab)

🔍 Screenshot replacement in words: "An empty white container, about 300px wide, where the list should appear"

🔍 Name reproduction steps: "1. Click Login → 2. Enter email → 3. Click Submit → page goes white"

---

When to use the Try-to-fix button?

✅ For red error messages in the console / preview ✅ When the app stays white after a build ✅ When Lovable itself says something went wrong

❌ Not for "looks wrong" — the button only fixes code errors, not design

---

When to reach for Version History?

Right away when:

• Multiple things are broken simultaneously
• You no longer remember which prompt broke what
• You've done 3+ follow-up prompts that each made things worse

Rule of thumb: If you've been fixing for 5 min and it's getting worse → roll back and re-prompt.

---

Part 6 — The workflow that always works

1. Sketch your idea in 2 sentences on paper ↓ 2. Run the Gemini/Claude interview using the meta-prompt above (5 min) ↓ 3. Read the resulting prompt once, adjust if needed ↓ 4. Paste into Lovable → wait 60-90 sec ↓ 5. CLICK THROUGH — like a real user. At least 2 min. Note what works and what doesn't. ↓ 6. Use Select & Edit to make targeted changes (NOT big follow-up prompts!) ↓ 7. If a bigger feature is missing: one second, focused prompt ↓ 8. CLICK THROUGH AGAIN — test before publishing. ↓ 9. Publish → share URL

---

Part 7 — Insights from real workshops

This section grows after every workshop. This is where the tricks participants discovered land.

Workshop 1 — Mikulov, [insert date]

(not yet held)

---

Update Log

• v0.1 — Initial version before Workshop 1 (Mikulov 2026)
• v0.2 — (update after Workshop 1)