Part 4: Finishing, Shipping, and Not Fucking It Up

Hi, it's G.

This is it. The final part.

If you made it here, you've done the documentation. You learned the vocabulary. You built and deployed something. You have a live URL.

Now comes the hard part: actually finishing.

Most people never get here. They build 80% of something, get distracted by a new idea, and start over. Their GitHub is a graveyard of half-finished projects. Their Vercel dashboard has 47 domains that redirect to nothing.

Don't be most people.

Part 4 is about the final 20%. The unsexy stuff. The polish. The edge cases. The "what happens when" scenarios. The maintenance plan. The decision to actually call something done and move on.

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

If you follow this part, you'll have a complete system for taking projects from idea to shipped product to maintained product to next product. A repeatable workflow that compounds over time.

Ready? Let's finish this.

Breaking Big Ideas into Small Pieces (The Lego Method)

AI chokes on big, vague requests.

"Build me a full e-commerce site" will produce garbage. Too many decisions. Too many assumptions. Too much room for hallucination.

The fix: break it into pieces.

The Lego Approach

Remember your IMPLEMENTATION_PLAN.md from Part 1? This is where it pays off.

Instead of "build the app," you have:

Phase 1: Setup
1.1 Initialize Next.js project
1.2 Install dependencies from TECH_STACK.md
1.3 Create folder structure

Phase 2: Auth
2.1 Install and configure Clerk
2.2 Create /login and /signup pages
2.3 Add protected route middleware
2.4 Test auth flow end-to-end

Phase 3: Core Features
3.1 Build recipe creation form
3.2 Connect form to Supabase
3.3 Build recipe list page
3.4 Build recipe detail page
3.5 Add edit functionality
3.6 Add delete with confirmation

Phase 4: Polish
4.1 Add loading states to all async operations
4.2 Add error states with retry options
4.3 Add empty states with helpful CTAs
4.4 Test on mobile
4.5 Test on different browsers

Each piece is one conversation. One task. One thing you can test independently.

Like building with Lego. You don't throw all the pieces in a pile and hope they form a castle. You build the foundation, then the walls, then the roof, then the details.

How to Break Down Any Feature

Take any feature. Ask these questions:

1. What's the simplest version that works?
2. What data does it need?
3. What does the user see?
4. What happens on success?
5. What happens on error?
6. What edge cases exist?

Example: Shopping cart feature

Simplest version: Add item to cart, show cart count

Data needed: Cart items array, quantities, prices

User sees: Add to cart button, cart icon with count, cart page listing items

Success: Item added, count updates, user sees confirmation

Error: Item unavailable, network failure, session expired

Edge cases: Adding same item twice, removing last item, cart with 0 items, cart with 100 items

Now you have your breakdown:

• Step 1: Add single item to cart (local state)
• Step 2: Display cart count in navbar
• Step 3: Create cart page showing items
• Step 4: Add quantity controls
• Step 5: Connect to backend for persistence
• Step 6: Add error handling
• Step 7: Handle edge cases

Each step builds on the last. Each can be tested. Each can be committed to git.

Tell AI Which Step You're On

"Build step 3.2 from IMPLEMENTATION_PLAN.md only. Don't jump ahead to 3.3."

This prevents AI from building everything at once and getting confused. One step at a time. Clean. Testable. Shippable.

Parang paglalakad. You don't teleport to the destination. You take one step, then another, then another. Eventually you arrive.

Scope Creep (And How to Kill It)

An endless feature list kills more projects than bad code.

You start building a recipe app. Then you think "what if it had meal planning?" Then "what if it calculated nutrition?" Then "what if it had social features?" Then "what if it had video tutorials?"

Six months later, you've built nothing. Because you kept adding features instead of finishing what you started.

The "Done" Definition

You're done when:

• The core feature works
• Users can complete the main action
• It doesn't break on common paths
• It's deployed and accessible

You're NOT done when:

• It's "perfect"
• Every edge case is handled
• It has every feature you imagined
• It looks exactly like Dribbble designs
• Your mom says it's good (joke lang, pero sometimes applicable)

The PRD is Your Contract

Remember PRD.md from Part 1? It has a section called "Out of Scope."

That section exists to save you from yourself.

When you get a new feature idea, check the PRD:

• Is it in scope? Cool, add it to the backlog.
• Is it out of scope? Write it down somewhere else and forget it for now.

Example from Resiboko:

In scope:

• Users can create recipes
• Users can save favorite recipes
• Users can search recipes
• Users can share recipe links

Out of scope:

• Meal planning
• Nutrition calculator
• Social features (comments, follows)
• Video tutorials
• Recipe ratings

Every time I thought "what if Resiboko had meal planning," I checked the PRD. Out of scope. Closed the tab. Kept building what was in scope.

Shipped the app in 7 days because I didn't chase every shiny idea.

The "Version 2" Document

Keep a separate file: V2_IDEAS.md

Every time you have a feature idea that's not in the current plan, dump it there.

# Version 2 Ideas

## Meal Planning Feature
- Weekly meal calendar
- Auto-generate shopping list from meal plan
- Drag and drop recipes to days

## Nutrition Calculator
- Add nutrition info to recipes
- Calculate daily totals
- Track nutrition goals

## Social Features
- Follow other users
- Comment on recipes
- Recipe collections

Now those ideas are captured. They won't haunt you. You can come back to them after V1 ships.

But V1 has to ship first.

Like building a house. You don't install the swimming pool before finishing the roof. First make it livable, then add the fancy stuff.

When AI is the Wrong Tool (And What to Do Instead)

AI is powerful. But it's not always the answer.

When to Use AI

• Generating boilerplate code
• Writing repetitive logic
• Exploring approaches quickly
• Debugging with context
• Translating intent into code
• Refactoring existing code

When to Learn It Yourself

• Core concepts (everything in this guide)
• How to read code AI generates
• How to spot when AI is wrong
• How to debug when AI can't help
• How your chosen stack fundamentally works

If you rely on AI for everything, you're building on quicksand. One weird bug and you're stuck.

The 80/20 Rule

AI does 80% of the typing. You do 100% of the thinking.

You decide what to build. You plan the architecture. You understand the flow. You verify the output. You test the edge cases.

AI is the translator, not the architect.

When Docs Beat AI

Sometimes official documentation is better than AI.

Use docs when:

• Learning a new framework for the first time
• The AI gives you outdated information
• You need the authoritative answer
• The AI is guessing and you need certainty

Example:

I was integrating Supabase auth. Asked Claude Code how to do it. It gave me code. Worked-ish. Had bugs.

Went to Supabase docs. Found the official auth guide. Followed it step by step. Worked perfectly.

Took 30 extra minutes. Saved me three days of debugging weird auth issues.

Sometimes reading the manual is faster than asking AI to interpret the manual for you.

Docs are like instruction manuals sa furniture. You can ignore them and try to figure it out, pero in the end, you'll probably screw something up and have to start over.

Advanced Workflows (When You're Ready)

Once you've built a few projects with the basic system, these techniques will multiply your speed.

These come from people who build production apps daily. Use them when you're comfortable with the basics.

Parallel Sessions with Git Worktrees

This is the single biggest productivity unlock I've learned.

Instead of working on one thing at a time, spin up multiple git worktrees. Each worktree is a separate working directory with its own branch.

How it works:

bash

# Main project in /my-app
cd my-app

# Create worktree for feature A
git worktree add ../my-app-auth feature/auth

# Create worktree for feature B
git worktree add ../my-app-dashboard feature/dashboard

# Create worktree for feature C
git worktree add ../my-app-api feature/api

Now you have three copies of your project. Each working on a different branch. Each can have its own Claude Code session running.

One terminal builds auth. Another builds the dashboard. A third builds the API. All simultaneously.

You bounce between them. Review outputs. Approve changes. Merge when done.

What used to take a full day of sequential building becomes a few hours of parallel execution.

Real example from AI For Pinoys dashboard:

• Worktree 1: Building the community feed
• Worktree 2: Building the events calendar
• Worktree 3: Building the member directory

All running at the same time. All building independently. Merged them one by one as they completed.

Built the entire dashboard in two days instead of a week.

Plan Mode as Your Force Multiplier

You already know to use planning (whether in Cursor, Claude, or your own notes). Here's how to make it even more powerful.

Two-stage planning:

Stage 1: Have Claude write the plan
Stage 2: Have another Claude session review the plan as a staff engineer

"Review this implementation plan. Find gaps, edge cases I missed, anything that will break. Be ruthlessly critical."

Fix the plan before writing code.

When things go sideways:

Stop immediately. Don't keep pushing. Switch back to plan mode.

"Here's where we are. Here's what broke. Re-plan from this point."

Get a new plan. Then continue building.

Voice Dictation for Better Prompts

You speak 3x faster than you type. Your prompts get dramatically more detailed as a result.

On Mac: Hit fn key twice to start dictating
On Windows: Win + H
On mobile: Use the microphone button

Describe what you want conversationally, with all the nuance and context you'd normally skip because typing is slow.

Example:

Typed prompt: "Add error handling to form"

Dictated prompt: "Add comprehensive error handling to the recipe creation form. If the image upload fails, show a clear error message and let them retry without losing their form data. If the title is empty, highlight the field in red and show validation text below it. If the API call fails, show a toast notification with the error and a retry button. If they lose internet connection mid-submit, save their form data to localStorage and let them resume when they're back online."

Same thought. Different level of detail. Better output.

Longer, more detailed prompts produce better results. Voice is the shortcut to getting there.

The lessons.md Self-Improvement Loop

Remember this from Part 3? Let me show you how powerful it becomes over time.

Every correction, every bug fix, every "don't do it that way" moment gets documented in lessons.md.

After 5 projects, your lessons.md has 50+ entries. It's a knowledge base of every mistake you've made and how to avoid it.

Point your CLAUDE.md at it: "Review lessons.md before making changes."

Now AI learns from your project history. The same mistake doesn't happen twice.

Real entry from my lessons.md:

## Lesson: Firebase Security Rules

Problem: Users could read other users' private recipes.

Root cause: Didn't set up security rules. Default Firebase rules allow read access to everything.

Solution: Write explicit security rules in Firebase console:
- Users can only read their own recipes
- Users can read public recipes from anyone
- Users can only write to their own recipes

Rule: ALWAYS set up security rules immediately after creating Firebase collections. Never deploy without them.

Next project using Firebase? Claude Code reads this. Sets up security rules from day one. No more exposed data.

This compounds. Your lessons.md becomes your personal coding manual.

Maintaining What You Built (The Unglamorous Part)

You shipped. Congratulations. Now you have to maintain it.

The Three Types of Maintenance

1. Bug fixes: Things break. Users report them. You fix them.

2. Feature additions: Users want more. You decide what to build next.

3. Technical debt: Code gets messy. Dependencies get old. You clean it up.

Monthly Maintenance Checklist

First week of the month:

bash

# Update dependencies
npm outdated
npm update

# Run tests
npm test

# Check for security vulnerabilities
npm audit
npm audit fix

Review lessons.md: Any patterns you noticed? Add them.

Review V2_IDEAS.md: Any ideas worth moving to the roadmap?

Check analytics: What are users actually doing? Any surprises?

Read user feedback: What are they complaining about? What do they love?

When to Refactor

You don't refactor because code is "ugly." You refactor when:

• Adding new features is getting harder
• The same bugs keep appearing
• New developers (or AI) can't understand the code
• Performance is suffering

Otherwise, leave it alone. Working code is good code.

Parang bahay. You don't renovate just because the paint is old. You renovate when the roof leaks or the foundation cracks.

Documentation Drift (And How to Prevent It)

As you build, your docs get out of date.

You add a feature. Forget to update PRD.md.
You change the database schema. Forget to update BACKEND_STRUCTURE.md.
You refactor the layout. Forget to update APP_FLOW.md.

After three months, your docs don't match your code. Now they're useless.

The fix:

After every major change, update the relevant docs.

Added auth? Update PRD.md and BACKEND_STRUCTURE.md.
Changed routing? Update APP_FLOW.md.
New design tokens? Update FRONTEND_GUIDELINES.md.

Make it part of your git commit:

bash

git add .
git commit -m "Added user profiles - updated PRD.md and BACKEND_STRUCTURE.md"

Now your docs stay current. Future you says thank you.

Cost Management (As You Scale)

Free tiers are generous. But when you get real users, costs appear.

What Costs Money

AI API calls:

• Claude API: Pay per token
• Google AI Studio: Generous free tier, then pay per request
• Gemini API: Similar pricing

Database:

• Supabase: 500MB free, then $25/month for Pro
• Firebase: Generous free tier, pay for reads/writes/storage

Hosting:

• Vercel: Free for hobby projects, $20/month for Pro
• Bandwidth costs kick in with traffic

File Storage:

• Supabase: 1GB free
• Firebase: 5GB free
• Cloudinary: 25GB free

Email:

• Resend: 3,000 emails/month free
• SendGrid: 100 emails/day free

Cost Optimization Strategies

1. Cache aggressively

Don't hit the database for every request. Cache common queries.

javascript

// Bad: hits database every time
const recipes = await getRecipes()

// Good: caches for 5 minutes
const recipes = await getCachedRecipes(300)

2. Optimize images

Use Next.js Image component. It automatically optimizes.

javascript

// Bad: loads full-size image
<img src="/huge-image.jpg" />

// Good: optimizes and lazy loads
<Image src="/huge-image.jpg" width={500} height={300} />

3. Limit API calls

Don't call external APIs on every page load. Call once, cache the result.

4. Monitor usage

Check your dashboards monthly:

• Vercel: bandwidth usage
• Supabase: database size, API calls
• Claude API: token usage

Spot problems before they become expensive.

When to Upgrade

Upgrade when you actually need to, not preemptively.

Signs it's time:

• Hitting free tier limits consistently
• Users experiencing slow performance
• Running out of storage
• Features blocked by free tier restrictions

Not signs:

• "I might get lots of users someday"
• "I want to look professional"
• "Everyone else pays for Pro"

Start free. Scale when forced. This saves hundreds per month.

Like buying pabahay. You don't get the biggest house you can afford. You get the house you need now, then upgrade when your family grows.

Security Beyond the Basics

You know the basics from Part 3. Here's what to worry about next.

Rate Limiting

Without rate limiting, someone can spam your API and rack up your costs.

Add rate limiting to API routes:

javascript

// Using Vercel's edge config
import { rateLimit } from '@/lib/rate-limit'

export async function POST(req) {
  const identifier = req.ip
  const { success } = await rateLimit(identifier)
  
  if (!success) {
    return new Response('Too many requests', { status: 429 })
  }
  
  // Process request
}

Common limits:

• 100 requests per minute for authenticated users
• 10 requests per minute for anonymous users
• 1 request per second for expensive operations

Input Validation

Never trust data from the client. Always validate on the server.

javascript

// Bad: trusts client data
const title = req.body.title
await saveRecipe({ title })

// Good: validates before saving
const schema = z.object({
  title: z.string().min(1).max(100),
  ingredients: z.array(z.string()).min(1),
  steps: z.array(z.string()).min(1),
})

const validated = schema.parse(req.body)
await saveRecipe(validated)

Use Zod or similar library. Define schemas. Validate everything.

SQL Injection Prevention

If you're writing raw SQL, use parameterized queries.

javascript

// NEVER do this
const query = `SELECT * FROM users WHERE email = '${email}'`

// Always do this
const query = 'SELECT * FROM users WHERE email = $1'
const result = await db.query(query, [email])

Or better: use an ORM or Supabase's built-in client. They handle this automatically.

CORS (Cross-Origin Resource Sharing)

If your frontend and backend are on different domains, configure CORS properly.

javascript

// In your API routes
export async function GET(req) {
  const headers = {
    'Access-Control-Allow-Origin': 'https://yourdomain.com',
    'Access-Control-Allow-Methods': 'GET, POST, PUT, DELETE',
    'Access-Control-Allow-Headers': 'Content-Type, Authorization',
  }
  
  return new Response(data, { headers })
}

Don't use '*' in production. Specify your actual domain.

Environment-Specific Secrets

Use different API keys for development and production.

# .env.local (development)
DATABASE_URL=postgresql://localhost:5432/dev
STRIPE_KEY=sk_test_...

# .env.production (on Vercel)
DATABASE_URL=postgresql://prod-db.supabase.co:5432/prod
STRIPE_KEY=sk_live_...

If you leak your dev keys, no big deal. If you leak prod keys, disaster.

Separate them. Protect prod keys like they're your ATM PIN.

The Complete System Recap (Everything in One Place)

Let's tie it all together. This is the entire workflow from idea to maintained product.

Phase 1: Interrogation and Documentation

Week 1, Day 1-2:

1. Use Claude to interrogate your idea
2. Answer every question until there are no assumptions
3. Generate your six canonical docs:
   • PRD.md
   • APP_FLOW.md
   • TECH_STACK.md
   • FRONTEND_GUIDELINES.md
   • BACKEND_STRUCTURE.md
   • IMPLEMENTATION_PLAN.md
4. Write CLAUDE.md with project rules
5. Create progress.txt with starting state
6. Create lessons.md (starts empty)
7. Create V2_IDEAS.md for future features
8. Initialize git and push to GitHub

Deliverable: Complete documentation. No code yet.

Phase 2: Rapid Prototype

Week 1, Day 3-4:

1. Use Lovable (for landing pages) or Google AI Studio (for apps)
2. Build the core feature only
3. Test that it works
4. Don't worry about code quality
5. Don't worry about edge cases
6. Just prove the concept works

Deliverable: Working prototype. Messy code. Core feature validated.

Phase 3: Production Build

Week 1, Day 5-7 or Week 2:

1. Take prototype to Claude Code
2. "Read all docs. Improve this prototype to production quality."
3. Work through IMPLEMENTATION_PLAN.md step by step
4. Commit after each working step
5. Update progress.txt after each feature
6. Update lessons.md when you fix bugs
7. Test on mobile after each feature

Deliverable: Production-ready code. Follows docs. Clean architecture.

Phase 4: Polish and Ship

Week 2-3:

1. Run through the verification checklist:
   • Works on mobile ✓
   • Works in different browsers ✓
   • Error states handled ✓
   • Loading states added ✓
   • Empty states with CTAs ✓
   • Edge cases tested ✓
2. Run Gemini code analysis
3. Fix issues found
4. Deploy to Vercel
5. Connect database (Firebase/Supabase)
6. Add environment variables
7. Test production URL
8. Ship

Deliverable: Live product. Actual URL. Real users can access it.

Phase 5: Maintenance

Ongoing:

1. Monthly dependency updates
2. Monthly security audit
3. Fix reported bugs
4. Update docs when code changes
5. Add lessons when patterns emerge
6. Review V2_IDEAS.md quarterly
7. Decide what to build next

Deliverable: Maintained product. Doesn't bit-rot. Stays current.

Knowing When to Stop (The Hardest Skill)

The best app you never ship is worse than the average app that's live.

Perfectionism kills more projects than technical problems.

The Shipping Checklist

You're ready to ship when:

• Core feature works
• Users can complete the main action
• Doesn't break on happy path
• Works on mobile
• Has loading states
• Has error states
• Has been tested by at least one other person
• You've used it yourself for a week

You don't need:

• Every feature you imagined
• Perfect design
• 100% test coverage
• Zero bugs
• Everyone's approval

Ship at 80%. Improve based on real feedback.

The Two-Week Rule

If you can't ship something meaningful in two weeks, you're building too much.

Break it down further. Find the smallest shippable version. Ship that. Then iterate.

Two weeks for V1. Then improve based on what users actually want, not what you think they want.

The Done-Done Definition

A project is done-done when:

1. It's live and accessible
2. Docs match the code
3. No critical bugs
4. You've told people about it
5. At least 10 people who aren't your friends have used it

Until then, it's not done. It's just built.

Like cooking. The food isn't done when it's cooked. It's done when it's plated, served, and eaten.

Your Final Checkpoint (Graduate from the System)

This is it. The final checkpoint. Complete this and you've officially finished the vibe coding system.

The Final Project Challenge

Build and ship a complete project in 14 days using everything you learned.

Day 1-2: Interrogation and documentation
Day 3-4: Rapid prototype
Day 5-10: Production build
Day 11-13: Polish and testing
Day 14: Ship

Requirements:

• All six canonical docs written
• CLAUDE.md and progress.txt maintained throughout
• At least one entry in lessons.md
• Prototype built with Lovable or AI Studio
• Production version built with Claude Code
• Deployed to Vercel with custom domain
• Database connected (Firebase or Supabase)
• Works on mobile
• At least 5 people (who aren't family) have used it
• You've shared it publicly (X, LinkedIn, anywhere)

Not required:

• Perfect design
• Every feature you imagined
• Viral success
• Revenue
• Everyone loving it

Extra credit:

• Set up git worktrees and build features in parallel
• Use voice dictation for at least one complex feature prompt
• Create a demo video showing how it works
• Write a blog post about what you learned building it

What to Build

Doesn't matter. Pick something you'll actually use.

Ideas if you're stuck:

• Personal dashboard (track habits, tasks, goals)
• Community tool (event calendar, member directory)
• Utility app (thumbnail generator, text formatter, link shortener)
• Niche tool for your specific industry
• Side project idea you've been putting off

The project itself doesn't matter. The system matters.

If you can take an idea and ship it in 14 days using this system, you can build anything.

What Comes After (Your Next Projects)

You've shipped one project. Now what?

Project 2: Faster

Use the same system. Should take 10 days instead of 14.

Why? Because you have:

• Your lessons.md from project 1
• Better understanding of the tools
• Muscle memory for the workflow
• Less decision paralysis

Project 3: Even Faster

Should take 7 days. Now you're starting to fly.

Your CLAUDE.md is refined. Your prompts are cleaner. Your architecture decisions are faster. You know which tools to use when.

Project 4-10: Consistent Shipping

By project 10, you can estimate accurately. "This will take 2 weeks." And it does.

This is the compound effect. Each project makes the next one easier.

Your lessons.md has 100+ entries. Your documentation templates are refined. Your tool workflow is smooth.

You're not learning the system anymore. You're using it.

When You're Ready: Teaching Others

Once you've shipped 5+ projects with this system, teach someone else.

Write your own version of this guide. Record videos. Share your lessons.md. Help others avoid your mistakes.

Teaching forces you to understand deeply. The system becomes even clearer when you explain it.

And honestly? There's something satisfying about helping someone else ship their first project. You remember how hard it was. Now you can make it easier for them.

Parang nagtuturo ka ng kapitbahay how to cook your lola's recipe. You learned it the hard way. Now you can save them the trial and error.

The System is Done. Now Go Build.

Four parts. Thousands of words. The complete vibe coding system.

Part 1: Documentation first, code second. The six canonical docs that prevent hallucinations.

Part 2: The vocabulary. UI vs UX, components, state, layout. The language of building.

Part 3: The tools and workflow. Claude Code, AI Studio, Lovable. Prototype fast, production-ready with Claude Code.

Part 4: Finishing and shipping. Breaking down features, killing scope creep, maintaining what you built, shipping consistently.

You now have everything you need to build and ship real products.

Not demos. Not tutorials. Real apps that solve real problems for real people.

The question isn't "can I do this?" anymore. You can. You have the system.

The question is: "Will I actually do this?"

Will you interrogate your next idea? Will you write the docs before coding? Will you follow the plan? Will you finish what you start?

Or will you skim this, get excited, then go back to building half-finished projects that never ship?

That's on you. I gave you the system. You have to use it.

My Final Challenge to You

Here's what I want:

30 days from now, send me:

1. A link to your deployed project
2. Your PRD.md (so I can see you actually did the docs)
3. One lesson from your lessons.md
4. What you learned building it

That's it. Not asking for perfection. Not asking for revenue. Not asking for thousands of users.

Just proof that you took this system and actually shipped something.

Because the world has enough people talking about building. Enough people starting projects. Enough people with ideas.

What we need are more people who finish.

Be one of them.

Go build something today.

— G

P.S. If you actually ship something in the next 30 days using this system, tag me. Share your project. I want to see what you built. And more importantly, I want to celebrate with you. Because shipping is hard, and you deserve to be recognized for doing hard things.

Walang perfect timing. Walang perfect project. Just start. Document. Build. Ship. Repeat.

The system works. Now prove it.