Bonus

Live Lovable demo

An optional walkthrough run only if time remains. Three build styles, one shared scenario — so the difference is the method, not the app.

The shared scenario — RequestRouter

One neutral, hackathon-safe app used across all three demos so the comparison is clean.

A small ops team receives incoming customer requests through a simple form.
Each request is auto-classified (Billing / Technical / General) and prioritised (High / Med / Low) with a short reason.
A dashboard lists requests sorted by priority, each with a suggested next action.

Screens below are illustrative mockups of the Lovable builder UI, not real captures. They show the shape of each moment in the build.

Demo 1 — One-shot build

Ask for everything at once

Show what not to do. Looks impressive on paper, breaks under the first real click.

Mega-prompt (anti-pattern)

Build a complete AI-powered business platform for handling incoming customer requests.
Include login, admin panel, analytics, email automation, CRM integration, role-based permissions, dashboards and reports.
Make it modern, professional, and fully functional.

1
One mega-prompt asks for the whole platform at once — auth, admin, analytics, CRM, email.
2
Lovable spins up dozens of files in one go. The preview fills with cards before anything is tested.
3
First click reveals a broken flow. Hard to debug, risky to demo, easy to lose the team.

Why this fails

No PRD, no phases, no testing in between. Lovable produces a lot of code, but you can't explain what was built, what works, or what to fix first. The demo is fragile.

Demo 2 — Phased build with PRD upload

The method we teach

Start with the PRD as the source of truth. Build in phases. Test between each phase. Ship a V1 you can actually demo.

Start here

Write the lightweight PRD first (see PRD builder guide), save it as a .md file, then drag it into Lovable's chat with the instruction below.

Phase 0 — Upload the PRD

Attach RequestRouter-PRD.md, then send

Use the attached PRD as the single source of truth for this build.
Build only what is listed under V1. Do not add anything that is not in the PRD.
If you think something is missing, ask me first instead of adding it.

Phase 1 — Plan before building

Ask for a plan, not code

Before writing any code, summarise the PRD back to me in your own words.
Then propose a 4–5 step build plan that delivers V1 in phases.
Do not start building until I confirm the plan.

Phase 2 — App shell only

Shell, no logic

Build the app shell only: top bar with the app name, left nav with two items — Intake and Dashboard.
Each page should be empty for now. No forms, no data, no styling extras.

Phase 3 — Intake form

Only the PRD fields

On the Intake page, add a form with exactly these fields from the PRD:
Title (text), Description (textarea), Channel (select: email / chat / phone), Customer email.
Add a Submit button. Do not save anywhere yet — just log the submission.

Phase 4 — Classification + priority

Decision logic + result card

When the intake form is submitted, classify the request as Billing, Technical, or General based on keywords in the description.
Assign priority High / Med / Low using a simple rule (e.g. words like "urgent", "overdue", "down" → High).
Show a result card with two badges (category + priority), a short reason, and a "Next action" suggestion.

Phase 5 — Dashboard + readiness check

Dashboard, then stop

On the Dashboard page, list all submitted requests sorted by priority (High first).
Show title, category, priority, and the suggested next action per row.
After this, stop building. We will run the demo readiness checklist before any further changes.

1
Drag the PRD into chat. Tell Lovable it's the source of truth and to ask before going outside V1.
2
Ask Lovable to summarise the PRD back and propose a build plan — before writing any code.
3
Phase 1 — build only the shell: navigation, empty Intake page, empty Dashboard page.
4
Phase 2 — add the intake form using the exact fields listed in the PRD. Nothing else.
5
Phase 3 — add classification + priority logic, with a clear result card and a next action.
6
Phase 4 — dashboard list sorted by priority. Then run the demo readiness check before anything else.

Why this wins

Every phase is small, testable, and tied back to the PRD. If anything breaks, you know exactly which phase caused it. The V1 is always demoable.

Demo 3 — Feature creep outside V1

Push back with the scope-control prompt

Even on a clean V1, the AI will happily expand scope. Your job is to classify, park, and protect.

The dangerous question

We have a working V1. What else should we add?

Scope-control prompt (use this reply)

For each suggestion you just made, classify it as one of:
• V1 — already in the PRD, keep it
• V2 — good idea, but park it for after the demo
• Not needed — does not serve the business decision

Do not implement any V2 or Not-needed items. Only confirm the V1 list.

1
Ask 'what else?' and Lovable will happily suggest notifications, auth, exports, analytics, CRM…
2
Apply the scope-control prompt. Each idea gets a tag — V1, V2 (parked), or Not needed.
3
V1 stays clean and demoable. Good ideas go to the V2 parking lot, not into the build.

What to watch for

Suggestions that sound harmless — "just add notifications", "just add login" — are how V1 gets broken the hour before the demo. The PRD and the parking lot are the boss.

Debrief questions

Which build felt safest to demo, and why?
What did the PRD actually prevent in Demo 2?
Which feature-creep suggestions deserved a V2 tag — and which were 'Not needed'?
Where did scope creep almost win, and what stopped it?

Where this connects

This bonus lesson pulls together the PRD, scope-creep pitfalls, and the demo checklist into one live walkthrough. Run it only if time remains — the method is the point, not the app.