Part 3: The Tools, The Build, The Ship

Hi, it's G.

If you made it to Part 3, congratulations. You've done the hard part. You wrote your documentation. You learned the vocabulary. You know what components are, what state means, how to describe layout.

Now comes the fun part: actually building the thing.

This is where most tutorials end with some vague "now just start coding" advice and leave you staring at a blank screen wondering where the hell to begin.

Not here. In Part 3, I'm walking you through the entire build process. The exact tools to use, when to use them, how to switch between them, how to iterate when things break, how to debug, and how to ship.

This is the part where your documentation becomes working code. Where theory becomes practice. Where you finally see why all that setup in Parts 1 and Part 2 was worth it.

But real talk lang: this only works if you did Parts 1 and Part 2 properly. If you skipped the checkpoint, if you didn't write your docs, if you're still saying "make it look good" instead of using specific vocabulary, Part 3 won't save you.

Documentation + Vocabulary + Tools = Working App

Skip any of those three and you're back to vibes and prayers.

Ready? Let's build.

The Tools You Actually Need (And How I Actually Use Them)

You don't need 50 tools. You need these. But you need to use them correctly.

Different tools for different phases of the build. Think of it like cooking. You don't use the same knife for everything. Pang-hiwang gulay, pang-hiwang karne, pang-slice ng tinapay, all different. Same concept here.

VS Code: Your All-in-One Workspace

VS Code is my main base. Where I see everything. Where I review changes. Where I run Claude Code from the terminal.

Some people love the fancy AI-native editors. I just need a solid code editor that doesn't get in my way. VS Code does that.

When I use it:

• Reviewing codebase changes after Claude Code runs
• Checking file structure
• Quick edits when I know exactly what to change
• Running terminal commands (including Claude Code)

It's my home base. Not flashy. Just works.

Claude Code: My Main Builder

This is where 90% of my actual coding happens.

Claude Code runs in the terminal. Reads CLAUDE.md automatically. Maintains context across the entire project. Works with the documentation system perfectly.

What I love about it:

• Terminal interface keeps me focused
• Handles multi-file changes cleanly
• Reads all my docs without me repeating myself
• With Opus 4.5? Sobrang galing. It actually understands what I'm trying to build.

When I use it:

• Everything. Literally almost everything.
• Building new features from IMPLEMENTATION_PLAN.md
• Debugging (this is my main debugger)
• Refactoring code
• Connecting frontend to backend
• Database migrations
• Code improvements after prototype phase

Real example from Resiboko:

Started with a prototype from Google AI Studio. Got it working. Then ran Claude Code:

"Read PRD.md and BACKEND_STRUCTURE.md. Migrate this Firebase prototype to production-ready code. Improve error handling. Add loading states. Follow FRONTEND_GUIDELINES.md for styling."

Claude Code read everything. Improved the code structure. Added proper error handling. Made it production-ready.

That's the workflow: prototype fast, then Claude Code for quality.

Google AI Studio: My Rapid Prototyping Tool

This is where I start when I need to see if an idea works.

When I use it:

• Initial prototypes to validate the concept
• Testing if a feature is even possible
• Quick demos to show clients or community
• When I need something working in hours, not days

Real examples:

Resiboko (expense tracker app): Google AI Studio for the prototype. Got the recipe form working, tested the flow, validated the idea. Then moved to Claude Code for production improvements.

Fit Check (outfit rating): Same flow. AI Studio for prototype. Validated the rating system worked. Then Claude Code with a detailed PRD for the production version.

The key: AI Studio is fast. I don't worry about perfect code. Just "does this idea work?" Once I know it works, Claude Code makes it production-ready.

Lovable.dev: My Landing Page Secret Weapon

Lovable is browser-based, visual, and honestly? Perfect for landing pages and simple MVPs.

When I use it:

• Landing pages for new projects
• When I need a clean frontend fast
• Marketing pages
• MVPs that are mostly frontend

Real example:

AI For Pinoys website and dashboard: Built entirely in Lovable. Walang Claude Code. Walang terminal. Just Lovable's visual editor.

Why? Because for that project, I didn't need complex backend logic. I needed a good-looking dashboard that worked. Lovable delivered that in a fraction of the time.

The website looks professional. Dashboard is clean. Users love it. Mission accomplished.

Pro tip: For multipage marketing sites or community dashboards where the backend is simple, Lovable is clutch. For complex apps with heavy backend logic, Claude Code.

Google Antigravity: The Multi-Agent Experiment

Antigravity is a VS Code fork that can run multiple agents simultaneously.

What makes it interesting: Multiple AI agents working on different parts of your code at the same time.

When I use it:

• Prototyping with parallel tasks
• When I want multiple agents tackling different features
• Experimenting with approaches

Real example:

Less Than A Minute (thumbnail generator): Started the prototype in Antigravity. Had one agent working on the image processing, another on the UI. Fast parallel development.

Then moved to Claude Code for improvements and production refinement.

It's experimental. It's fun. It's fast for certain types of projects. But Claude Code is still my main workhorse for production work.

Gemini: My Code Analysis Tool

I use Gemini (via Google AI Studio or direct API) for code review and analysis.

When I use it:

• Analyzing the codebase through GitHub
• Getting suggestions for improvements
• Code review before big deploys
• Finding optimization opportunities

How it works:

Connect Gemini to my GitHub repo. "Review the codebase. Find performance issues, security gaps, and code that could be simplified."

It scans everything. Gives me a report. I take the suggestions to Claude Code to implement.

Two-tool workflow: Gemini finds issues, Claude Code fixes them.

The Multi-Tool Workflow (How They Actually Work Together)

Here's my real system:

Phase 1: Prototype (Fast and Messy)

For landing pages/simple MVPs: Lovable

• Build it visually
• Get it working
• Deploy
• Done

For complex apps: Google AI Studio or Antigravity

• Build rough prototype
• Test core functionality
• Validate the idea works
• Don't worry about code quality yet

Goal: Prove the concept works. Ship fast. Get feedback.

Phase 2: Production (Clean and Solid)

Claude Code + Opus 4.5

Take the prototype. Make it production-ready.

"Read PRD.md and all canonical docs. Review this prototype code. Improve structure, add error handling, follow design system, make it production-grade."

Claude Code refactors everything. Adds proper error states. Follows the docs. Makes it maintainable.

This is where good ideas become good products.

Phase 3: Debug and Improve

Still Claude Code

When bugs appear (and they will), Claude Code is my debugger.

"This feature is breaking when users do X. Debug and fix."

It traces the issue. Fixes it. Tests. Done.

Plus Gemini for analysis:

Every few weeks: "Gemini, analyze the codebase via GitHub. Find issues."

Take the report to Claude Code: "Fix the issues Gemini found."

Phase 4: Deploy

Vercel for multipage websites and web apps Firebase for single-page apps that need a database (like Resiboko) Supabase for projects with complex auth and data needs (like AI For Pinoys)

Push to GitHub. Vercel auto-deploys. Firebase/Supabase handles the backend. Live.

Real Project Workflows

Let me show you exactly how I built each project:

Resiboko (Expense App)

Day 1: Google AI Studio prototype
Built the recipe form. Tested saving to Firebase. Validated the core flow worked.

Day 2-3: Claude Code production improvements
"Improve this prototype. Add error handling. Follow FRONTEND_GUIDELINES.md. Make it production-ready."

Day 4: Claude Code debugging
Fixed edge cases. Improved loading states. Handled offline scenarios.

Deploy: Firebase for database, Vercel for hosting.

Fit Check Muna (Outfit Checker App)

Day 1: Google AI Studio prototype
Built the rating system. Tested image uploads. Core feature validated.

Day 2-4: Claude Code with detailed PRD
Wrote comprehensive PRD. Had Claude Code rebuild with proper architecture. Added user profiles. Improved rating algorithm.

Day 5: Claude Code debugging
Fixed the three crashes. Improved performance.

Deploy: Vercel + Firebase.

Less Than A Minute (Thumbnail Generator)

Day 1: Antigravity prototype
Multi-agent approach. One agent on image processing, one on UI. Fast prototype.

Day 2-3: Claude Code improvements
Refined the image generation logic. Improved UI. Added export options.

Deploy: Vercel.

AI For Pinoys Website + Dashboard

Full project: Lovable only
Designed in Lovable. Built in Lovable. Deployed from Lovable.

No Claude Code needed. No terminal. Lovable handled everything.

Backend: Supabase for auth and database.

Why Lovable worked: Project was frontend-heavy. Dashboard was visual. No complex backend logic. Lovable's visual editor was perfect for this.

My Honest Tool Preferences

Favorite overall: Claude Code with Opus 4.5
It just understands what I'm trying to build. Reads my docs. Follows patterns. Produces clean code.

Favorite for prototyping: Google AI Studio
Fast. No setup. Just build and test.

Favorite for landing pages: Lovable
Visual. Clean output. Perfect for marketing sites.

Favorite for code analysis: Gemini
Scans the whole repo. Finds issues I miss.

Never tried but hear good things about:
Cursor (everyone raves about the four modes)
Kimi K2.5 (sounds great for visual design replication)
Codex (the parallel debugging sounds useful)

Maybe I'll try them someday. But honestly? My current stack works. Claude Code + Opus 4.5 is doing everything I need.

Walang sense mag-experiment with new tools kung yung current tools mo are already shipping production apps consistently.

Why Terminal > Visual Editors (For Me)

A lot of people love the visual AI editors. I get it. They're pretty. They're intuitive.

But I prefer the terminal. Here's why:

Focus: No visual distractions. Just me, the terminal, and the code.

Speed: Terminal commands are faster than clicking through menus.

Control: I see exactly what's happening. No black box magic.

Habits: I've been using terminals since before AI coding was a thing. It's muscle memory.

Your mileage may vary. Some people thrive in visual environments. I thrive in the terminal. Find what works for you.

The tool doesn't matter as much as the system. Documentation + Vocabulary + Consistent Workflow = Shipped Products.

The Tools You Actually Need (Simplified)

If you're just starting, here's the minimum stack:

For prototyping:

• Lovable (if visual) OR Google AI Studio (if code-first)

For production:

• VS Code (or any code editor)
• Claude Code (via Anthropic API or Claude Pro)

For deployment:

• Vercel (hosting)
• Supabase or Firebase (backend/database)

For version control:

• GitHub

That's it. Five tools. Everything else is optional.

Start here. Add more tools when you actually need them. Not because they're trendy.

Like buying kitchen equipment. Start with a good knife, a pan, and a pot. You don't need a sous vide machine until you're actually making sous vide.

GitHub: Where Your Code Lives (Non-Negotiable)

GitHub is version control. Every change is tracked. You can go back to any previous version.

Why this matters:

You break something? Revert to the last working version.
You want to try something risky? Create a branch, experiment, merge if it works, delete if it doesn't.
You lose your laptop? Your code lives on GitHub, not just locally.

The basics:

bash

git add .                    # Stage your changes
git commit -m "Added recipe detail page"  # Save with a message
git push                     # Upload to GitHub
git pull                     # Download latest changes

The system:

Commit often. After every major feature that works.

"Added user login"
"Added product grid"
"Fixed checkout bug"

If you break something, you can always go back. Like quicksave in a video game. You wouldn't fight a boss without saving first, right? Same logic.

Connect this to your progress.txt:

Commit code → update progress.txt → push both

Now GitHub has your code AND your context file. Next session, pull down, read progress.txt, keep building.

Vercel: Where Your App Goes Live

Your code works on your computer. Now it needs to work on the internet.

The process:

1. Push code to GitHub
2. Connect GitHub repo to Vercel
3. Vercel automatically builds and deploys
4. You get a URL like your-app.vercel.app
5. Add your environment variables in Vercel's dashboard

When something works locally but breaks on deploy:

Give AI the Vercel error logs.

"It works on localhost but breaks on Vercel. Here's the error from Vercel's logs:" (paste error)

99% of deploy bugs are:

• Missing environment variables
• Wrong build settings
• Wrong Node version

All fixable in minutes once you give AI the logs.

Supabase: Your Database and Auth

Supabase is the easiest start for backend.

What it handles:

• Database (PostgreSQL)
• Authentication (email, Google, GitHub, etc.)
• File storage
• Real-time subscriptions

Free tier is generous. You can build and ship without paying anything until you scale.

The setup:

1. Create project on Supabase
2. Create tables (use the SQL from your BACKEND_STRUCTURE.md)
3. Copy your API keys to .env
4. Connect from your app

Done. You have a backend.

When to use it:

• You need user accounts
• You need to save user-generated content
• You need a database that grows
• You want auth handled for you

When NOT to use it:

• Static site with no user interaction
• Landing page that just collects emails through a form service

Simple rule: if users create accounts or save data, use Supabase. If not, you probably don't need it.

Your Documentation System in Practice (How It All Connects)

Remember those six canonical docs from Part 1? Here's how they get used during the actual build.

PRD.md: Your Source of Truth

When AI tries to add a feature you didn't ask for, point it back to the PRD.

"Only build what's in PRD.md. This feature is out of scope."

When you're deciding what to build next, check the PRD. It kills scope creep before it starts.

Like a wedding coordinator with a checklist. "Is this in the program? No? Then we're not doing it."

APP_FLOW.md: Your Navigation Map

Reference this when building page transitions and user journeys.

"Build the login flow exactly as documented in APP_FLOW.md section 3."

AI now knows every screen, every redirect, every error state in that flow.

TECH_STACK.md: Your Dependency Lock

Gets referenced at project initialization and whenever AI tries to introduce a new dependency.

"Use only the packages listed in TECH_STACK.md. Do not add new dependencies without asking."

This prevents AI from randomly importing libraries you didn't approve. Like a bouncer at a club. "You're not on the list? You're not coming in."

FRONTEND_GUIDELINES.md: Your Design System

AI should reference this for every component it creates.

"Style this component per FRONTEND_GUIDELINES.md section 2."

Consistent design across every file. No random colors. No inconsistent spacing.

BACKEND_STRUCTURE.md: Your Data Blueprint

"Create the users table as defined in BACKEND_STRUCTURE.md section 2.1."

AI builds exactly the schema you specified. Not its own interpretation.

IMPLEMENTATION_PLAN.md: Your Build Sequence

"We're on step 4.2 of IMPLEMENTATION_PLAN.md. Build this step only."

This prevents AI from jumping ahead or building things out of order.

Like cooking a recipe. You don't put the icing on before baking the cake. Follow the steps.

CLAUDE.md: The Living Document

CLAUDE.md is your master configuration file. It sits in your project root and Claude Code reads it automatically every session.

What it contains:

• Tech stack summary
• Naming conventions
• File structure
• Component patterns
• Forbidden actions
• References to all six docs

Think of it as the operating system manual AI loads before doing anything.

The Self-Improvement Loop

Here's the move most people miss: CLAUDE.md is a living document.

Every time AI makes a mistake and you correct it, end with: "Edit CLAUDE.md so you don't make that mistake again."

Over time, your CLAUDE.md becomes a self-improving rulebook. The mistake rate drops measurably because AI is literally encoding its own corrections.

Example:

AI keeps putting components in the wrong folder.

You: "Components go in src/components/, not app/components/. Update CLAUDE.md."

AI updates CLAUDE.md with: "All components must go in src/components/. Never create them in app/components/."

Next session, AI reads that rule. Doesn't make the mistake again.

lessons.md: Your Mistake Log

Take it further with a lessons.md file.

After every correction, after every PR, after every debugging session, update lessons.md with:

• The pattern that caused the issue
• The rule that prevents it

Point your CLAUDE.md at it: "Review lessons.md at session start for relevant context."

Now AI learns from its own history on your project.

Example lessons.md entry:

## Lesson: Image Upload Error Handling

Problem: Photo uploads were failing silently. Users didn't know it failed.

Root cause: No try/catch on upload function. No loading state. No error display.

Solution: Always wrap upload functions in try/catch. Show loading state. Display error message if upload fails. Allow retry.

Rule: Every upload function must have:
1. Loading state
2. Try/catch block
3. Error message display
4. Retry option

Next time AI builds an upload feature, it reads this. Includes proper error handling from the start.

This is the self-improvement loop that separates good CLAUDE.md from great ones.

progress.txt: Your Session Bridge

Remember this from Part 1? Now you see why it matters.

After every feature:

COMPLETED:
- User auth via Clerk (login, signup, Google OAuth)
- Dashboard layout with sidebar navigation
- Products API endpoint (GET /api/products)
- Product list page with grid layout

IN PROGRESS:
- Product detail page (/products/[id])
- Need to connect frontend to API
- Need to add loading state

NEXT:
- Shopping cart functionality
- Checkout with Stripe

KNOWN BUGS:
- Mobile nav doesn't close after clicking link (low priority)

When you open a new terminal, start a new Claude Code session, switch branches, or come back after a week, AI reads this and knows exactly where you are.

No "what were we working on?" No rebuilding context. No re-explaining your entire project for the 69th time.

Update it religiously. After every feature. This is your external memory.

The Actual Build Process (Step by Step)

Alright, enough theory. Here's how you actually build.

Phase 1: Setup (Do This Once)

Step 1: Create project folder

bash

mkdir my-app
cd my-app

Step 2: Initialize git

bash

git init
git add .
git commit -m "Initial commit"

Step 3: Push to GitHub Create repo on GitHub, then:

bash

git remote add origin https://github.com/yourusername/my-app.git
git push -u origin main

Step 4: Initialize your project per TECH_STACK.md

If you're using Next.js:

bash

npx [email protected] .
```

Install dependencies from TECH_STACK.md.

**Step 5:** Create folder structure per your docs
```
src/
├── app/
├── components/
├── lib/
└── styles/

Step 6: Copy your docs into the project root

All six canonical docs, CLAUDE.md, progress.txt, lessons.md. Everything.

Step 7: Initial commit

bash

git add .
git commit -m "Project setup complete, docs added"
git push

Now you're ready to build.

Phase 2: Building Features (Do This Repeatedly)

Step 1: Read progress.txt

What's next in the plan?

Step 2: Use Cursor Plan mode (or Claude) to architect the feature

"I'm building step 4.2 from IMPLEMENTATION_PLAN.md. Create a detailed plan."

Review the plan. Adjust if needed. Approve.

Step 3: Use Cursor Agent mode to build

"Build the plan we just created. Follow FRONTEND_GUIDELINES.md for styling. Reference APP_FLOW.md for navigation."

Let it finish. Don't interrupt mid-build.

Step 4: Test the feature

Does it work? Does it look right? Test on desktop. Test on mobile.

Step 5a: If it works, commit

bash

git add .
git commit -m "Added recipe detail page"
git push
```

Update progress.txt:
```
COMPLETED:
- Recipe detail page (/recipes/[id])
- Fetches data from API
- Styled per FRONTEND_GUIDELINES.md
- Works on mobile

NEXT:
- Add edit functionality
```

Step 5b: If it breaks, debug

Use Cursor Debug mode or give AI the error:

"I'm getting this error: [paste error]. Here's the code: [paste code]. Here's what I expected: [describe]."

Fix it. Test again. Then commit.

Step 6: Repeat for next feature

Go back to step 1. Build the next thing in your plan.

This is the loop. Plan → Build → Test → Commit → Next.

Reading Error Messages (The Skill Nobody Teaches)

Errors are not insults. They're instructions.

Most people panic and ignore them. Don't do that.

Anatomy of an Error

TypeError: Cannot read property 'map' of undefined
    at ProductList (src/components/ProductList.tsx:15:23)

Translation:

• TypeError: You're using something wrong
• Cannot read property 'map' of undefined: You tried to use .map() on something that doesn't exist
• ProductList.tsx:15:23: Exact file and line number

When You Get an Error

Give AI everything:

"I'm getting this error: [full error message]

Here's the code at that line: [paste relevant code]

Here's what I was trying to do: [describe]

Here's what I expected to happen: [describe]"

The more context, the faster the fix.

Common Errors and What They Mean

"Cannot read property X of undefined"
Something is undefined when you try to use it. Usually missing data or wrong variable name.

"Module not found"
You're trying to import something that doesn't exist. Typo in import path or missing package.

"Unexpected token"
Syntax error. Missing bracket, comma, or quote somewhere.

"Type X is not assignable to type Y"
TypeScript error. Your types don't match. Fix the type definition.

"Failed to compile"
Check the terminal for the specific error. Usually a syntax issue.

Learn to read errors. They're trying to help you. Parang yung kapitbahay na nagpapaalala na naka-bukas yung ilaw mo. Annoying but helpful.

The Debugging Loop (When Things Break)

Things will break. That's normal. The skill is iterating quickly.

The Loop:

1. AI gives you code
2. You try it
3. It breaks
4. You paste the error
5. AI fixes
6. Repeat until it works

This is not failure. This is the process. Vibe coding isn't one-shot (even though we love when it is). It's iteration.

For Stubborn Bugs:

If a bug survives two or three rounds of this loop, switch tools.

Option 1: Cursor Debug Mode

Generates multiple hypotheses. Instruments your code with runtime logs. Walks through the bug methodically.

Option 2: Codex

Give it the bug description. Let it trace through your codebase. It reads the entire repo before proposing a fix.

Option 3: Start Fresh

Sometimes the code is too broken. Delete the file. Rebuild it from scratch using the plan. Faster than trying to fix spaghetti code.

Like when you're untangling Christmas lights. Sometimes it's easier to just buy new ones.

Git Workflows for Vibe Coding

Git isn't just for backing up. It's for experimenting safely.

The Basic Flow

bash

# After each working feature
git add .
git commit -m "Added feature X"
git push

For Risky Changes

bash

# Create a branch
git checkout -b experiment

# Make changes
# Test

# If it works
git checkout main
git merge experiment
git push

# If it doesn't work
git checkout main
git branch -D experiment

Now you can try things without fear. If it breaks, just delete the branch. Main branch stays clean.

Verifying Before You Ship (The Checklist)

Before deploying, check:

• Does it work on mobile? (Actually open it on your phone)
• Does it work in different browsers? (Chrome, Safari, Firefox)
• What happens with no data? (Empty states handled?)
• What happens with wrong data? (Error states handled?)
• What happens with slow internet? (Loading states exist?)
• Can you break it by clicking fast? (Test rapid interactions)
• Are secrets hidden from browser dev tools? (Check .env)
• Does it work when logged out? (If relevant)
• Are images optimized? (No massive file sizes)
• Does it load fast? (Check performance)

Don't ship until you've answered these. Your users will find every bug you missed.

Seryoso. They will. And they'll tell you about it in the reviews. "1 star, doesn't work on my phone." Ouch.

Deploying to Vercel (Making It Live)

You've built it. It works locally. Now make it live.

First Time Setup:

1. Go to vercel.com
2. Sign up with GitHub
3. Import your repo
4. Vercel auto-detects Next.js
5. Add environment variables from your .env
6. Click Deploy

Done. You get a URL.

Every Update After:

Just push to GitHub. Vercel automatically rebuilds and redeploys.

bash

git add .
git commit -m "Fixed mobile nav bug"
git push

Wait 2 minutes. Your changes are live.

That's it. No manual deployment. No server management. Just push code, Vercel handles the rest.

Like having a butler for your code. "Sir, your changes are now live. Will that be all?"

Cost Awareness (The Thing Nobody Talks About)

Everything has a cost. Know what you're paying for.

Free Tiers:

Vercel: Generous free tier for hobby projects
Supabase: 500MB database, 1GB file storage, 50,000 MAU
Clerk: 5,000 MAU free
GitHub: Unlimited public repos

You can build and ship without paying anything until you scale.

AI Tools:

Cursor Pro: ~$20/month, covers most model access
Claude Pro: ~$20/month if you need more Claude access
ChatGPT Plus: ~$20/month if you're using Codex heavily
Kimi K2.5: Free through Kimi.com, generous API pricing

You don't need every paid tier on day one. Start with Cursor Pro and one other. Add more when your workflow demands it.

Scaling Costs:

When you actually get users:

• Database storage (past free tier)
• API calls (if using external APIs)
• File storage (if users upload images/videos)
• Email sending (for transactional emails)

But these only matter when you're successful. Don't architect for millions of users on day one. Start free. Scale when you need to.

Like worrying about parking space for your Lamborghini when you haven't even bought a car yet. One problem at a time.

Security Basics (So You Don't Get Hacked)

The bare minimum to not screw up:

Never Expose Secrets

• API keys stay in .env, never in frontend code
• .env is in .gitignore (never committed to git)
• Never screenshot code with API keys visible
• Use different keys for development and production

Always Validate Backend

• Don't trust anything from the browser
• Validate all inputs on the server
• Check authentication before allowing actions
• Use Supabase RLS (Row Level Security) to enforce database permissions

Use HTTPS

Vercel does this automatically. Just make sure you're using the https:// URL.

Keep Dependencies Updated

Old packages have known vulnerabilities.

bash

npm outdated        # Check what's outdated
npm update          # Update packages
```

Do this monthly. Takes five minutes. Prevents most common attacks.

Use Auth Services

Don't roll your own authentication. Use Clerk or Supabase Auth. They handle password hashing, session management, token refresh, all the hard security stuff.

Like why would you build your own lock when Master Lock exists? Use what's proven secure.

You're not building a bank. But you should know the basics so you don't ship obvious vulnerabilities and get clowned on Twitter. That's everyone's worst nightmare.

Third-Party Services (Use What Exists)

You don't build everything from scratch. You plug in services for the hard parts.

When to Use a Service:

When the feature isn't your core product.

Your core product is the unique thing you're building. Everything else is infrastructure. Use existing services for infrastructure.

Common Services:

Auth: Clerk, Supabase Auth
Payments: Stripe
Database: Supabase, Firebase
Email: Resend, SendGrid
File Uploads: Uploadthing, Supabase Storage
Analytics: Vercel Analytics, Plausible
Error Tracking: Sentry

Pick one in each category. Don't overthink it. They all work. Just choose and move on.

Like choosing pancit canton flavor. Calamansi, chilimansi, sweet and spicy, whatever. Just pick one and cook. You're not building a pancit empire, you're just hungry.

Your Part 3 Checkpoint

You made it. You now know the tools, the workflow, the build process, how to debug, how to deploy.

This is where documentation becomes working code. Where planning becomes shipping.

Here's what you need to do before Part 4:

Practical Checkpoint:

Step 1: Build and deploy your first feature

Pick the first item from your IMPLEMENTATION_PLAN.md. Could be just the navbar. Or the hero section. Something small.

• [ ] Use Plan mode to architect it
• [ ] Use Agent mode to build it
• [ ] Test it on desktop and mobile
• [ ] Commit to git
• [ ] Deploy to Vercel
• [ ] Verify it works live

Example: "Built and deployed the navbar component. Works on all screen sizes. Committed to git. Live at myapp.vercel.app."

Step 2: Fix at least one bug using Debug mode

Intentionally break something if you have to. Then use Debug mode or Codex to fix it.

The goal: experience the debugging loop. Learn how to read errors. Get comfortable with iteration.

Step 3: Update progress.txt and lessons.md

After your feature is done:

COMPLETED:
- Navbar component built and deployed
- Works on desktop (tested Chrome, Safari)
- Works on mobile (tested iPhone, Android)
- Styled per FRONTEND_GUIDELINES.md
- Deployed to Vercel successfully

KNOWN ISSUES:
- None yet

NEXT:

• Hero section (step 2.2 from IMPLEMENTATION_PLAN.md)

If you hit any bugs during the build:

## Lesson: Mobile Nav Animation

Problem: Mobile menu animation was janky on iOS.

Root cause: Used transform instead of translate. iOS doesn't handle transform well.

Solution: Changed to translate3d for GPU acceleration.

Rule: For mobile animations, always use translate3d instead of transform.

Step 4: Test the multi-tool workflow

Try this sequence:

1. Ask Claude to help you plan a new feature
2. Use Cursor Agent to build it
3. If you need visual accuracy, try K2.5 on one component
4. Use Codex to review the code

You don't need to finish the feature. Just experience using different tools for different phases.

Step 5: Practice git branching

bash

# Create an experimental branch
git checkout -b test-new-layout

# Make some changes
# Test

# If you like it
git checkout main
git merge test-new-layout
git push

# If you don't
git checkout main
git branch -D test-new-layout
```

Now you know how to experiment safely.

If you completed this checkpoint, you've officially built and shipped something. Kahit maliit lang, it's live. That's huge.

If you didn't, that's fine too. But know that Part 4 assumes you've actually built something. The next part is about finishing, polishing, maintaining. You can't maintain what you haven't built.

In Part 4, we're covering the final mile. Breaking big ideas into small pieces. Knowing when to stop. Maintaining what you built. Handling scope creep. Using advanced workflows (parallel sessions, subagents, voice dictation). And the complete system recap that ties everything together.

This is where good projects become great ones. Where you learn to actually finish and ship consistently, not just build demos that sit on localhost forever.

See you in Part 4.

— G

P.S. If you actually deployed something to Vercel, send me the link. I want to see what you built. Seriously. Even if it's just a navbar. Ship with pride. Every big app started as just a navbar.