AI Vibe Coding Workshop · Day 2

From Idea
to Product.

Yesterday you built pages people can see. Today you give your app a memory, a lock on the door, and a real product around it — and you ship it.

Your Day, Module by Module

Day 2 at a glance.

A clear arc: in the morning you design and build the pieces. After lunch you join them into one product, test it, and present it.

9:00
Welcome & the big picture — how today's product comes together
9:35
Define your product — what, for whom, which screens
10:10
Build the landing page — the page that sells it
10:55
Build the prototype — your screens, clickable
11:40
Confirm your flows — a robot tests it for you
11:50
Build the database — give your app a memory
12:45
Lunch
13:45
Build the full app — connect everything together
15:15
Final test — make sure it works for a stranger
15:45
Showcase — present what you built
17:00
Done — a real product, live.
The golden rule: your database is finished before lunch. Everything in the afternoon builds on it.
Where We're Going

By 5pm, you walk out with four things.

Not slides about a product. The product itself — built, secured, and live on the internet.

👀
A landing page
The page that sells your product to a stranger.
📱
A working prototype
Your screens, clickable — the flow of your app.
🗃️
A secure database
A memory that keeps each user's data private.
🚀
A full app, live
All of it connected, deployed, and shareable.
One sentence to keep in your pocket: "The one thing I'm most afraid won't work today." Write it down now. We'll come back to it at 5pm.
Picking Up Where We Left Off

Yesterday the face. Today the brain.

Day 1 you built pages people can look at. They're real, they're live — but they forget everything the moment you refresh. Today we fix that.

Yesterday — Day 1
🎨 Pages that show & react
🌐 A live URL anyone can visit
🚫 But it forgets on refresh
Today — Day 2
🧠 A memory that remembers (database)
🔒 A lock so each user sees only their own
📦 A real product wrapped around it
Same skill you learned yesterday — describe what you want, let AI build it — pointed at bigger pieces.
How Your App Reaches the World

From your laptop to a live link.

Your code doesn't magically appear online. It travels down a little assembly line — and today we add the last piece at the bottom.

💻
Your code
written by AI, owned by you
🐙
GitHub
saves every version, safely
Vercel
builds it & puts it online
🌐
Your live product
anyone, anywhere, right now
⇅ reads + writes
🗃️
Supabase NEW TODAY
remembers your data, securely
You already built the top three yesterday.
Code → GitHub → Vercel → a live URL. That's the exact path your Day 1 page took to get online. You don't have to think about it — it just happens when you save.
Today you add the bottom box.
Supabase is the part that remembers — bookings, accounts, messages, anything your app needs to keep. By 12:30 your app has all four pieces: a real production stack.
The Tool That Keeps You Safe

GitHub is your project's time machine.

Think of the save points in a video game. Every time you save, you can always go back if something goes wrong. GitHub does that for your whole project — automatically, forever.

📖
Every version, saved
Nothing is ever truly lost. Made a mess? Roll back to any earlier save in seconds.
☁️
A backup in the cloud
Your laptop dies, your project doesn't. It lives safely on GitHub's servers.
🔗
The engine behind "live"
When you save to GitHub, Vercel notices and updates your live site on its own.
You won't write any of the commands by hand — your AI tools do it for you. But knowing what's happening makes you fearless. Here's the whole flow →
Six Words You'll Hear All Day

The GitHub workflow.

Read it like a map. The main line is your real project. You branch off to try something safely, then merge it back when it works.

main feature branch commit branch ↑ work safely merge (via PR)
💾
Commit
A save point, with a note on what changed.
⬆️
Push
Send your saves up to GitHub.
⬇️
Pull
Bring the latest version back down.
🌿
Branch
A safe copy to try things, without touching the real version.
📥
Pull Request (PR)
"Here's my change — review it before it goes in."
📥
Merge
Fold the working change back into the main line.
The Magic That Happens After You Save

Save it once. It ships itself.

This is CI/CD — a fancy term for one simple promise: the moment you save to GitHub, your site rebuilds and goes live on its own. No "uploading", no buttons.

💾
You save
push to GitHub
⚙️
It builds
Vercel assembles it
🚀
It deploys
pushed worldwide
🌐
It's live
~30 seconds later
📦
Why it matters today: every fix you make this afternoon is live in under a minute. Change → save → refresh the real site. That's your loop.
Two New Superpowers for Claude

Skills give it know-how. MCPs give it hands.

Today Claude isn't just chatting. It has expert playbooks loaded in its head, and live connections to real tools it can actually operate.

🧠
Skill
A trained specialist's playbook
Like hiring a consultant who already knows exactly how to write a product brief or plan a database. It changes how Claude thinks.
Run once per job — you don't re-run the planner mid-build.
🤝
MCP
A live connection to a real tool
Like giving that consultant the keys to your database and a web browser. It changes what Claude can touch — Supabase, a real browser, a video generator.
Always on — call it anytime. When something breaks this afternoon, the MCP is usually the fix.
Simple rule: Skills for planning. MCPs for building & testing.
Your Toolkit · One Map

Nine helpers, one day.

You'll meet each one when you need it. Here's the whole team so nothing feels like a surprise.

Helper
Type
What it does for you
prd-generator
Skill
Interviews you into a clear product brief
prd-desk-research
Skill
Sanity-checks the idea — go, refine, or stop
prd-to-ux-brainstorm
Skill
Lists every screen before you build
ui-ux-pro-max
Skill
Picks a design style, colours & fonts
design-md-brand-ref
Skill
Real design recipes from 73 top products
data-content-planner
Skill
Turns your screens into a plain-English data plan
Supabase MCP
MCP
Builds your database for you — no code
Seedance 2 MCP
MCP
Makes a moving hero video from a sentence
Playwright MCP
MCP
A robot that clicks through your app to test it
01
Module 1

Define Your
Product

Before you build anything, get crystal clear on what it is and who it's for. Three quick skills do the heavy lifting — you just answer honestly.

Why This First

You wouldn't build a house without a blueprint.

Skip this and the AI guesses — you get a generic app for no one. Answer three questions and you get a builder brief you'll reuse all day.

What are we building?
The product, in plain words.
prd-generator
⚖️
Is it worth building?
A second opinion + a sceptic's view.
prd-desk-research
📄
Which screens does it need?
A list of every page to build.
prd-to-ux-brainstorm
The three answers become one block of text. Copy it — it's the most valuable thing you'll write today.
Your Turn

Run the three skills in order

STEP 1 — describe it Type "run prd-generator" and answer its questions. Your first answer is usually the right one. Don't overthink. STEP 2 — check it Paste your brief, type "run prd-desk-research". Read only the verdict + the sceptic. Adjust if it says "stop". STEP 3 — map the screens Paste your brief, type "run prd-to-ux-brainstorm". Copy the builder brief at the end — you'll use it all day.
Goal
A copied builder brief before you move on.
Stuck on an idea?
"What do you do by hand every week that you hate?" Build that.
02
Module 2

Build the
Landing Page

If you can't explain your product in one sentence, you can't build it either. So we write that sentence first — as the page that sells it.

Your Product's Shop Window

Four parts. Copy before colour.

A passer-by decides in seconds. Every strong landing page answers four things — write the words first, make it pretty second.

1
Headline
The change you cause, in one line. Not what it does — what's different after.
2
Subheadline
Who it's for, and how it works — one sentence.
3
Proof
One real number, result, or named type of user.
4
Call to action
One clear button. "Start your first booking" — never "Learn more".
1 · HEADLINE
Book staff in 30 seconds,
not 30 emails.
2 · For cafe owners who juggle shifts by hand.
4 · Start your first roster →
3 · Used by 40+ KL cafes
Then bring it alive: a slow looping hero video behind the words. One feeling word — calm, bold, trustworthy — is your whole video prompt.
Your Turn

Write → style → go live

1 · WRITE THE WORDS In a blank doc, write your: headline · subheadline proof line · button text Specific beats clever.
2 · GET A LOOK run ui-ux-pro-max product + feeling word run design-md-brand-ref note style · colour · font
3 · HERO + BUILD "6s looping hero video, feeling: [word]" (Seedance) Paste brief + words + look + video into your builder.
Goal before the break A landing page that exists. Any landing page. Perfect is for later.

Quick break.

You've got a brief, a validated idea, a design direction, and a landing page with a moving hero. Stretch — the fun part is next.

03
Module 3

Build the
Prototype

Don't design the filing cabinet before you know what you're filing. First build the journey through your app — the data comes after.

What's a Prototype?

The test drive before the engine.

A prototype is your app with the screens connected but no real data yet. You click through it to feel the journey — fix the path before you build the plumbing.

🚪
Entry
they arrive
Core action
they do the thing
Result
they see it worked
Build just your three most important screens first. If you can click entry → action → result, the prototype is done.
Your Turn

Build the skeleton

1. Paste your builder brief into your builder. Add: "Build this as a clickable prototype. Navigation should work, data can be fake. Focus on the user journey." 2. Open it and use it like a stranger — don't read the code. 3. Note the 3 things that feel most wrong (fix later). 4. Fix the worst navigation problem — one prompt. 5. Click it end to end: entry → action → result.
If you get stuck Tell the builder the exact path: "Let a user go from [A] to [B] to [C]." Can't finish? Cut a screen until the path works.
Module 4 · A Robot Tests It For You

You know where to click. A stranger doesn't.

Testing your own app is the least reliable test — you skip the confusing bits without noticing. Playwright is a robot that opens your app fresh and tries to use it, then tells you what broke.

1. Publish your prototype → live URL 2. Type: "Using Playwright MCP, test my app at [URL]. Try three things: 1) a new user does the main action 2) moving between my screens works 3) the form with an empty field" 3. Fix the top thing it found — re-test.
Cheap now, expensive later
A broken flow caught now takes 5 minutes. The same thing found after you've built the database takes 45.
Fix one thing — the one that stops a stranger finishing. The rest can wait.
05
Module 5 · Done before lunch

Build the
Database

Your flows work. Now give your app a memory that supports exactly those flows — and a lock so each person only sees their own data.

What's a Database?

A filing cabinet with a lock.

A database is just a tidy filing cabinet for your app's data. You don't write any code — you name the things you store, and Supabase MCP builds the cabinet for you.

📝
Name the "things"
A thing is any noun your app saves — a booking, a contact, a task. Name them; the skill builds the rest.
🤖
Claude builds it live
Supabase MCP creates every table for you while you watch. No spreadsheets, no SQL, no copy-paste.
🔒
Lock every drawer (RLS)
A rule so each person opens only their own drawer. Without it, everyone sees everyone's data.
The lock takes 30 seconds to add now. Fixing a leak after launch takes 45 minutes. Always lock it first.
Your Turn

Plan it → let Claude build it

PART A — plan the data Paste your screens, type "run data-content-planner" Confirm the "things" it finds. Answer: does it need login? Is each person's data private?
PART B — build it Confirm Supabase MCP (green) Paste the plan, type: "create the tables + a lock so each user sees only their rows." Watch the tables appear. Green shield = locked.
Before lunch Every table shows a green shield. That's your whole afternoon unblocked.
🎉
Halfway · Before Lunch

Your idea now has infrastructure.

This morning it was a sentence. Now it has a real, secured database behind it. Post it on the wall:

"[App name] helps [who]
do [what]. Database: done."
🍽️

Lunch.

You're walking in with a live landing page, a working prototype, and a secured database. The hard thinking is done — this afternoon you just connect the pieces.

06
Module 6

Build the
Full App

Prototype, database, landing page — all built. Now you join them into one real product where the data actually saves.

Your Turn

Connect · complete · polish

You're not rebuilding — you're wiring your prototype to your real database, then filling in the screens you skipped.

1. Tell the builder: "Connect my app to Supabase. Use the public (anon) key." 2. Test it: does data save and still show after a refresh? 3. Build the leftover screens, one prompt each. Last 15 min: polish only, no new features.
🧹
The Stranger Test — at the 45-min mark
Hand your app to the person next to you. 60 seconds, no explanation. Watch. They say one sentence: "The first thing I tried to do was…" Fix exactly that.
Use the public key, not the secret one — the secret key turns off your lock.
Module 7 · The Robot's Final Round

One last check before you present.

Same robot as this morning, now testing the real thing — including the lock. You're looking for one answer: can a brand-new user get all the way through?

"Using Playwright MCP, full test at [URL]: 1) sign up + do the main action 2) data saves + survives a refresh 3) a user sees only their own data 4) the form handles an empty field" Fix the single most important fail. Re-run it.
If test 3 fails
Someone can see another person's data — the lock has a gap. One prompt to Supabase MCP fixes it.
Can't fix in 5 minutes? Present your prototype instead — it works, and that's a perfectly good showcase.
07
Module 8

Showcase

Don't show them your app. Show them the problem it solves — then let the app prove it.

Three Minutes Each

Tell a tiny story.

Not a feature tour. A before, a moment, and an after.

30s
The problem
Specific and personal. Before this existed, what happened?
90s
The demo
Open your landing page, read the headline, then do the one main action live. Show the moment the problem disappears.
60s
What changes
What's different about someone's day because this now exists?
Open with the landing page, not the app. Let them read your headline — that's your opening line.
Day 2 Complete

An idea this morning.
A product tonight.

👀 Landing page 📱 Prototype 🗃️ Secure database 🚀 Full app, live

Remember that fear you wrote at 9am? Read it again. You answered it — not because AI did the work, but because you showed up with a real problem and shipped the answer.

AI is your co-pilot, not your replacement.