Second Project — Domain Deep Dive

Topics

• Project scoping: defining requirements
• Breaking complex projects into phases
• Working with external APIs
• Data visualization: charts, maps
• Progressive enhancement
• Documentation: READMEs that matter

Activities

• Choose your second project — pick something you personally care about
• Write a detailed project brief
• Build in phases: data first, then logic, then UI, then polish
• Deploy to Vercel with a professional README
• Self-review using /code-review

Skills You'll Gain

Project scoping, phased development, external APIs, data visualization

Learning Objectives

By the end of this week, you will be able to:

1. Scope a project by defining an MVP (minimum viable product)
2. Write user stories that describe features from the user's perspective
3. Work with external APIs (understand API keys, rate limits, and documentation)
4. Build in phases, shipping a working version at each stage
5. Write a professional README that helps others understand and use your project

Lesson

Project Scoping: What to Build

This week you will build a second application — one you choose yourself. The best projects are ones you will actually use. Here are some ideas:

• Habit Tracker — Track daily habits (exercise, reading, water intake) with streaks and charts
• Book Reading Log — Record books you have read, want to read, with ratings, notes, and recommendations
• Local Weather Dashboard — Pull real-time weather data for your city with forecasts and historical charts
• Recipe Collection — Store, search, and organize your favorite recipes by ingredient, cuisine, or meal type
• Expense Tracker — Log daily expenses, categorize them, and visualize spending patterns
• Workout Logger — Track exercises, sets, reps, and progress over time

Or pick anything that excites you. The goal is genuine motivation — you will work harder and learn more building something you actually want.

Scoping: From Dream to MVP

The biggest mistake beginners make is trying to build everything at once. The solution is an MVP (Minimum Viable Product) — the smallest version of your app that is actually useful.

Ask yourself: "If I could only build 3 features, which ones would make this app worth using?"

Example for a Habit Tracker:

• Dream version: Custom habits, daily tracking, weekly/monthly charts, friend challenges, push notifications, AI-powered suggestions, social feed...
• MVP: Create habits. Check them off daily. See a 7-day streak count.

The MVP is version 1.0. Everything else is version 2.0, 3.0, etc. Ship the MVP first, then iterate.

User Stories: Describing Features

User stories describe features from the user's perspective. They follow a simple format:

As a [type of user], I want to [do something], so that [benefit].

Examples for a Habit Tracker:

• "As a user, I want to create a new habit with a name, so I can track it daily."
• "As a user, I want to check off a habit for today, so I can record my progress."
• "As a user, I want to see my current streak for each habit, so I stay motivated."

Write 5-8 user stories for your MVP. These become your checklist during development.

Working with External APIs

Many interesting apps pull data from external services. An external API is someone else's server that provides data you can use in your app.

What is an API key? Most APIs require a key — a unique string that identifies you. It is like a library card: the library (API) needs to know who you are and how much you are using their resources.

To get an API key:

1. Sign up on the API provider's website
2. Navigate to their developer dashboard
3. Generate an API key
4. Store it in your .env.local file (never commit it to Git!)

Rate limits: APIs limit how many requests you can make per minute/hour/day. This prevents abuse. A free tier might allow 100 requests per day. If you hit the limit, you get an error.

Reading API documentation: Every API has docs explaining what data is available and how to request it. Ask Claude Code: "Read the OpenWeather API docs and show me how to get the current weather for a city."

Popular free APIs for projects:

• OpenWeather — Weather data (free tier: 1,000 calls/day)
• Open Library — Book data (no key needed)
• Spoonacular — Recipe data (free tier: 150 calls/day)
• NewsAPI — News articles (free tier: 100 calls/day)

Building in Phases

Build your project in this order:

1. Phase 1: Data — Design your database schema. What tables do you need? What columns? Set up Supabase tables.

2. Phase 2: Logic — Build your API routes. Create, read, update, delete your data. Test each endpoint.

3. Phase 3: Interface — Build the user-facing pages. Connect them to your API. Make the basic flow work.

4. Phase 4: Polish — Improve styling, add animations, handle edge cases, fix bugs. Make it professional.

At the end of each phase, you should have a working (if incomplete) app. This is called progressive enhancement — your app gets better layer by layer, and it works at every layer.

Writing READMEs That Matter

A README is the front door of your project. When someone visits your GitHub repository, the README is the first thing they see. A good README answers:

1. What is this? — One sentence explaining the project
2. Why does it exist? — The problem it solves
3. What does it look like? — A screenshot or demo link
4. How do I set it up? — Step-by-step installation instructions
5. How do I use it? — Key features and how to access them
6. What technologies does it use? — Tech stack list

Ask Claude Code: "Write a professional README for my project that includes setup instructions, a feature list, and a tech stack section."

Practice Exercises

Exercise 1 (Guided): Project Brief and Schema

1. Choose your project from the ideas above (or your own)
2. Write 5 user stories for your MVP
3. Design the database schema (tables and columns)
4. Ask Claude Code to create the Supabase tables
5. Insert 3-5 test rows of data manually

Verification: Your Supabase dashboard shows the tables with test data. Your user stories are documented in a docs/project-brief.md file.

Exercise 2 (Independent): Build the MVP

Goal: Build and deploy a working MVP with at least these features:

• User can create new items (habits, books, recipes, etc.)
• User can view all items in a list
• User can update or delete items
• Data is saved permanently in Supabase
• App is deployed to Vercel

Use Plan mode for the overall architecture, then build phase by phase. Commit after each phase.

Hints:

• Reuse patterns from your task manager (CRUD, auth, Tailwind)
• Ask Claude to help you integrate any external API you need
• Test thoroughly after each phase before moving to the next

Verification: The app is live on Vercel. You can perform all CRUD operations. Data persists after closing the browser.

Exercise 3 (Challenge): Professional Polish

Take your deployed MVP and make it professional:

• Add a chart or visualization (use Recharts or similar)
• Write a complete README with screenshots
• Add authentication (if not already done)
• Run /code-review and fix all issues
• Share the GitHub link and live URL

Document your development process in a docs/build-log.md — what went well, what was hard, what you would do differently.

Self-Assessment Quiz

1. What is an MVP, and why should you build one before the "full" version?

2. Why should you scope a project before building it?

3. What is an API rate limit, and what happens if you exceed it?

4. What are the essential sections of a good README?

Answers:

1. MVP stands for Minimum Viable Product — the smallest version of your app that is actually useful. You build the MVP first because trying to build everything at once leads to overwhelm, unfinished projects, and wasted effort. Ship the MVP, get feedback, then add features iteratively.

2. Scoping means defining exactly what you will build before you start. Without scoping, you might start building, realize the project is too big, and abandon it. Scoping helps you identify the MVP, set realistic goals, and build in an organized sequence.

3. A rate limit is the maximum number of API requests you can make in a given time period (e.g., 100 requests per day). If you exceed it, the API returns an error instead of data. You should handle rate limit errors gracefully in your code and cache responses when possible.

4. A good README includes: (1) What the project is (one sentence), (2) Why it exists (the problem it solves), (3) What it looks like (screenshot or demo link), (4) How to set it up (installation steps), (5) How to use it (key features), (6) What technologies it uses (tech stack).

Claude Developer Platform & Web Access

• Claude Developer Platform (platform.claude.com) — Centralized hub for managing API keys, usage, billing, and project configuration.
  • API key management and rotation
  • Usage dashboards and token consumption tracking
  • Project and organization settings
  • Model access configuration
• Claude Code on the Web (claude.ai/code) — Browser-based access to Claude Code. Complements the CLI workflow for quick tasks or when terminal access isn't available.

Exercise: Visit the Claude Developer Platform and explore the usage dashboard. Review your API key setup and ensure your Claude Code CLI is authenticated correctly. Identify how token usage maps to the sessions you've run.