Practice Layer · Gap 2
Do
the
Work
3 Projects · 3 Levels
Step-by-step instructions
Prompts · Checklists · Reflection
Reading about vibe coding is not the same as vibe coding. These three projects give you structured, hands-on practice — with real instructions, copy-paste prompts, and clear success criteria for each stage.
Pick the project that matches your level. Complete it fully before moving to the next guide. The knowledge only sticks when you build something real.
🌱 Beginner — Budget Tracker
⚡ Intermediate — Habit Tracker API
🔧 Builder — SaaS Refactor
Reading about building is not building. These projects are your first real steps toward something that matters.
THE COMPLETE SERIES Included in The Complete Series ($29).
🌱
Beginner
Personal Budget Tracker
A simple browser-based app to log daily expenses by category and see a running monthly total. No sign-in, no database — just localStorage and a clean interface. Real enough to use, simple enough to finish in one session.
Time: 2–3 hours
Tool: Bolt or Claude
Stack: HTML/CSS/JS (no framework)
Outcome: Working app you can actually use
1
Complete the Intent Worksheet (15 min)
15 min
Before opening any AI tool, answer these four questions in writing — even rough notes. This is the most important step and the one most beginners skip. Don't skip it.
1
What does it do? Complete the sentence: "This app helps [me / freelancers / someone] to [core action] so they can [outcome]." One sentence maximum.
2
Who is it for? Describe the user — even if it's just you. What's their situation before this app exists? What frustrates them?
3
What does "done" look like? Write the exact 3–5 step journey a user takes. Example: "Open app → add a £4.50 coffee under Food → see the Food total update → see my overall total for the month." That's your done test.
4
What are you NOT building? List 3 things that won't be in this version. "No login, no charts, no export." Constraints protect scope.
2
Write Your First Prompt (10 min)
10 min
Use the template below, filling in your answers from Phase 1. This becomes your opening prompt to the AI. Read it out loud — if any sentence is vague, rewrite it before sending.
Your First Prompt — Fill In The Brackets
# What I'm building I'm building a personal budget tracker. It helps [your user] to [core action] so they can [outcome]. # The user experience (v1 only) The user can: 1. Add an expense (amount, category, optional note) 2. See a list of all expenses for the current month 3. See a total per category 4. See the overall monthly total That's it. Nothing else for v1. # Constraints - No login or authentication - Store data in localStorage (browser only) - No external libraries except vanilla JS - No charts or graphs — numbers only - Mobile-friendly layout # What I want first Before writing any code: confirm you understand what I need, then show me the HTML structure you'd use. Don't build it yet.
Why ask for structure first?
You're asking the AI to confirm your shared understanding before it writes any code. If its proposed structure looks wrong, correct it now — before you've accepted code you don't want.
3
Build Phase — 4 Focused Iterations (60–90 min)
60–90 min
Once the AI has confirmed the structure, use these four prompts in order. Run the code after each one before moving to the next. If something breaks, paste the error back before continuing.
Iteration 1 — Core Structure
Build the HTML/CSS/JS for a basic expense tracker with: - An "Add Expense" form: amount (number), category (dropdown with Food, Transport, Entertainment, Bills, Other), and an optional note field - A list showing all expenses with their category and amount - localStorage to save and load expenses automatically Use clean, minimal styling — no frameworks. Cream background, dark text.
Iteration 2 — Category Totals
Add a totals section above the expense list that shows: - Total spent per category (only show categories that have entries) - Overall monthly total - Make these update automatically when an expense is added or deleted
Iteration 3 — Delete + Polish
Add a delete button to each expense item. When clicked, show a brief "Are you sure?" confirmation before removing. Also add a "Clear all" button at the bottom that requires a confirm dialog. Keep the styling consistent with what we have.
Iteration 4 — Edge Cases
Handle these edge cases: 1. Prevent submitting the form with an empty amount or £0 2. Show a friendly message when there are no expenses yet ("No expenses yet — add your first above") 3. Format all amounts as £X.XX consistently 4. Make sure the page works on mobile (test the layout at 375px width)
4
Test Against Your Done Test (20 min)
20 min
Go back to the done test you wrote in Phase 1. Walk through it exactly. Then run these additional checks.
Add 5 expenses across 3 categories — do the totals update correctly?
Refresh the page — are all expenses still there?
Try submitting the form empty — does it prevent it?
Delete one expense — does the total update?
Open on a phone or resize to 375px — is it usable?
!
Enter a very large number (999999999) — does it display gracefully?
!
Enter a negative number — does it prevent it or handle it?
You're Done When
You can add, view, and delete expenses
Category totals update in real time
Data survives a page refresh
The form rejects empty or zero entries
You could hand this to a real person and they'd understand it
5
Reflection — What Did You Learn? (10 min)
10 min
This is the most underrated step. Spend 10 minutes answering these questions in a notebook or doc. The reflection is where learning consolidates.
Reflection Questions
What went exactly as you expected?
What surprised you — about the AI's output or the process?
Where did you need to correct the AI? What was the correction?
What would you do differently in the next project?
What's the one thing you'd add to this in a v2?
Intermediate
Habit Tracker with a Local API
A full-stack habit tracker: a React frontend, a Node/Express API backend, and SQLite storage. Real architecture decisions, real separation of concerns, real error handling — the kind of thing you'd actually put in a portfolio or hand to a client.
Time: 3–5 hours
Tool: Cursor (recommended)
Stack: React + Express + SQLite
Outcome: Full-stack app with real architecture
1
Architecture Conversation First (20 min)
20 min
Before writing any code, have an architecture conversation. This is the Principle 5 exercise: own the architecture before the AI builds it.
Architecture Prompt
I'm building a habit tracker with: - React frontend - Node/Express REST API - SQLite via better-sqlite3 Features for v1: 1. See all habits with today's completion status 2. Mark a habit complete/incomplete for today 3. Add a new habit (name + optional target days/week) 4. See a 7-day streak for each habit Before writing code: recommend a folder structure, the database schema, and the main API routes. Give me 2 options with tradeoffs. I'll choose, then we build.
After the AI responds: Evaluate both options. Choose one and tell the AI why. This decision-making is Principle 5 in action — you own the architecture.
2
Backend First — API + Database (60 min)
60 min
Backend Build Prompt
Build the Express backend using the structure we agreed. Include: - GET /habits — return all habits with today's completion status - POST /habits — create a new habit - PATCH /habits/:id/complete — toggle today's completion - GET /habits/:id/streak — return 7-day streak data Database: SQLite with better-sqlite3 Two tables: habits (id, name, target_days, created_at) and completions (id, habit_id, date, completed_at) Include error handling for missing habits (404) and invalid inputs (400). Add a CORS header for localhost:3000.
Test the API before building the frontend. Use curl or a REST client to hit each endpoint. Fix issues now — it's much easier than debugging through the UI.
GET /habits returns an array (empty is fine)
POST /habits creates a habit and returns the new record
PATCH /habits/1/complete toggles the completion and returns updated status
Requesting a non-existent habit returns 404, not a crash
3
Frontend — React UI (60–90 min)
60–90 min
Frontend Prompt
Build a React frontend that connects to our Express API at localhost:3001. Components needed: 1. HabitList — fetches and displays all habits 2. HabitCard — shows habit name, today's status (complete/incomplete toggle), and 7-day streak dots 3. AddHabitForm — name input + optional target days, POST to API on submit State management: React useState + useEffect only (no Redux) Styling: plain CSS modules, clean and minimal Error states: show a message if the API is unreachable Loading states: show a spinner or "Loading..." while fetching Start with HabitList and HabitCard. Get those working first.
4
Security + Error Handling Review (30 min)
30 min
Run the AI security audit before you consider this done. This is the Principle 4 exercise.
Security Review Prompt
Review our backend code for: 1. Input validation — are all inputs validated server-side? 2. SQL injection — are we using parameterised queries? 3. Error messages — do any errors leak internal details to the client? 4. Missing error cases — what inputs could cause an unhandled exception? Show each issue with the vulnerable code and the fix.
Done When
All 4 API endpoints work and return correct data
Completing a habit updates the UI immediately
7-day streak displays correctly
Adding a habit persists after page refresh
Security review passed with no critical issues
5
Reflection (15 min)
15 min
Intermediate Reflection
Where did the AI's architecture differ from what you'd have chosen alone? Was its choice better or worse?
Did the security review find anything you would have shipped without noticing?
Which principle from the Six Principles guide did you most consciously apply?
What would the next iteration of this project need? Write the Intent Worksheet for it.
🔧
Builder
Multi-File Codebase Refactor + Feature Add
Take a real legacy codebase (we provide it) and use vibe coding techniques to: understand it quickly, refactor a problematic module, add a new feature, and do a security pass — all while maintaining the architecture and not breaking what works.
Time: 2–4 hours
Tool: Cursor or Claude Code
Stack: Node.js (provided codebase)
Outcome: Cleaner code + new feature + security pass
1
Understand Before Changing — Codebase Audit (30 min)
30 min
The most important builder discipline: understand the existing system before changing it. Use the AI to understand, not to change — yet.
Codebase Understanding Prompt
I have an existing Node.js codebase. I'll share the files one at a time. For each file, tell me: 1. What it does (one sentence) 2. What it depends on 3. Any patterns or conventions I should maintain 4. Any obvious problems you notice Don't suggest changes yet — just help me understand what I have. Start with the entry point: [paste your main file]
For this exercise: Use your own codebase, or clone any small open-source Node.js project. The skill is the technique — not the specific codebase.
2
Context Document — The Builder's Secret Weapon (20 min)
20 min
After the audit, create a context document. This is what makes every future AI session with this codebase dramatically better. Paste it at the start of every session.
Context Document Prompt
Based on our audit, create a context document I can paste at the start of future sessions. It should include: - What this codebase does (2-3 sentences) - The main modules and what each does - Key conventions and patterns to maintain - Known issues or technical debt - Things to never change without careful review Format it for easy copy-paste. I'll use this as my "project memory" across conversations.
3
Targeted Refactor — One Module (45 min)
45 min
Choose the most problematic module from your audit. Refactor it — but not everything at once. Pick the single most impactful change.
Refactor Prompt Template
[Paste context document] I want to refactor [specific module/file]. The specific problem: [what's wrong with it] The goal: [what better looks like] Constraints: - Don't change the public interface (other modules call it the same way) - Maintain the existing error handling patterns - Don't add new dependencies - Keep the same file structure Show me the refactored version with comments explaining the significant changes.
Run all existing tests before refactoring — establish a baseline
Commit the working state before applying the refactor
Run tests again after — nothing should break
Read the diff — do you understand every change?
4
Add a New Feature — Using the Existing Architecture (60 min)
60 min
Add one new feature to the refactored codebase. The goal is to add it in a way that fits naturally with the existing architecture — not a bolt-on.
Feature Addition Prompt
[Paste context document] I want to add: [your feature] Before implementing: how would you approach this given our existing architecture? Which files would change? Would you add new files? What pattern would match our existing conventions? Once I agree on the approach, implement it.
5
Security Pass + Reflection (30 min)
30 min
Builder Security Pass
Review all the code we've added or modified in this session. Check specifically: 1. Input validation on the new feature 2. Error handling — what happens with malformed input? 3. Are there any new attack surfaces? 4. Does the new code maintain our existing security patterns? Then: what are the top 3 technical debt items you'd address in the next session?
Builder Reflection
How did using the context document change the quality of the AI's output?
Where did the AI make an architectural assumption you had to correct?
What's in the technical debt list from the security pass?
At what point in this session did you most feel "I'm steering, not following"?