Capstone: Ship a Real Python Project

#Pick your project

#Option A: CLI LLM Pet Project · Beginner · ~4 hours

A command-line chatbot powered by Claude. The user picks a "persona" — cooking coach, code reviewer, stoic philosopher, tarot reader, dungeon master, midwestern aunt — and chats with it from the terminal. The chat history persists across runs so the bot remembers prior conversations.

Architecture hint

• personas.json — a dict of {persona_name: system_prompt} so adding a new persona is a 2-line change
• chat_history.json — append every user/assistant turn so the bot has memory between sessions
• chat.py — the CLI entry point: picks a persona, loads history, loops on input(), calls the API, prints the reply, saves history

#Option B: Personal Data Analyzer · Intermediate · ~6 hours

• Spotify listening history (request your data from Spotify — comes as JSON)
• GitHub commit history (use the GitHub REST API or git log --pretty=format: exported to CSV)
• Screen-time export from your phone
• Browser history (history.sqlite on most browsers)
• Fitness app data (Apple Health, Strava, Garmin)

Architecture hint

• analyzer.py — a DataAnalyzer class with methods load(), compute_stats(), top_n(), by_month()
• report.py — formats the stats into a Markdown or plain-text report
• main.py — CLI entry point parsing --input file.csv --output report.md

#Option C: Mini FastAPI Service · Advanced · ~8 hours

Architecture hint

• main.py — FastAPI app with route handlers
• models.py — Pydantic schemas (JokeIn, JokeOut, ErrorOut)
• service.py — business logic, separated from routing so it's testable
• tests/ — at least 3 pytest tests hitting the API via TestClient

#Option D: Propose your own · Any difficulty

If none of the above fit you, write your own. Constraints:

1. Must be a single coherent Python project (not 5 disconnected scripts).
2. Must produce something a real user, including a non-programmer in your life, can actually use.
3. Must touch at least 4 skills from the prerequisite recap above.

#The build process: 4 phases

You're not going to write everything at once. You're going to build it the way professionals do: one slice at a time, running the code constantly.

#Phase 1: Plan (30 minutes)

• Write a 1-paragraph spec: What does it do? Who uses it? What's the input, what's the output?
• Sketch the file structure. Three to five files is right for this size of project.
• List the 3-5 functions or classes you'll need. Just the names and one-line descriptions — no implementation yet.

That's it. Resist the urge to start coding. Spec first.

#Phase 2: Skeleton (1 hour)

• Create the empty files.
• Define every function signature with pass as the body.
• Add a docstring to each function explaining what it should do when implemented.
• Run python main.py (or whatever your entry point is) and verify the import graph doesn't crash. The skeleton should run silently — no logic, no output, no errors.

This phase feels pointless. It is not. A working skeleton you can extend feature by feature is what makes the difference between finishing and stalling.

#Phase 3: Implement (most of the time, ~2-5 hours)

Pick ONE function. Make it work end-to-end. Test it manually in the terminal. Move on to the next function. Repeat.

#Phase 4: Polish (1 hour)

• Write the README (template below — copy/paste it).
• Add error handling for the obvious failure modes: missing files, bad API keys, malformed input, empty user input.
• Take a screenshot of it working, or record a 30-second screen recording. This is for your portfolio and your LinkedIn post.
• Run the whole thing one more time on a clean terminal as if you were a stranger. Did anything surprise you? Fix it.

#A starter for Option A: the persona chatbot

If you picked Option A, here is a minimal skeleton to get you past Phase 2. Edit, run, extend.

#The README template: copy this exactly

# Project Name

> One-sentence tagline. What it does, in plain English.

## What it does

A 3-5 sentence paragraph explaining the problem you wanted to solve, who
it's for, and what the program does. Plain English. No jargon. Imagine
explaining it to a smart friend who doesn't code.

## Demo

![Screenshot of the app running](./demo.png)

(Or embed a 30-second screen recording, or a link to a deployed URL.)

## Setup

```bash
# 1. Clone the repo
git clone https://github.com/your-username/your-project.git
cd your-project

# 2. Create a virtual environment and install dependencies
python -m venv .venv
source .venv/bin/activate     # macOS / Linux
# .venv\Scripts\activate      # Windows
pip install -r requirements.txt

# 3. Set your API key (if applicable)
export ANTHROPIC_API_KEY=sk-ant-...
```

## Usage

```bash
python main.py --input data.csv --output report.md
```

Sample output:

```
=== Personal Data Analyzer ===
Loaded 1,243 rows.
Top track: "Sunset Lover" — 89 plays
Most-listened month: October 2025
Report saved to report.md
```

## How it works

A 1-paragraph architectural overview. What are the main files? What does
each one do? What's the data flow from input to output? Don't reproduce
the code — describe the *shape* of it.

## What I learned

- One specific technical lesson (e.g., "Pydantic's validation errors are
  way more useful than try/except chains.")
- A second specific lesson — ideally one you got wrong first, then fixed.
- A debugging story — the bug that took you the longest to find.
- One thing about your own process (e.g., "I shipped faster once I stopped
  trying to design the whole API before writing any of it.")

## What I'd add next

- A concrete feature you'd add with another week.
- A second feature — something a real user has asked for, or that would
  obviously improve the product.
- An infrastructure or quality improvement (tests, CI, deployment, logging).
```

The "What I learned" and "What I'd add next" sections are the ones that turn a project from "homework" into "this person thinks like an engineer." Do not skip them.

#Get an AI code review

Once your project runs end-to-end, drop your full code into the reviewer below. Claude is genuinely good at this — better than most code reviews you'll get as a junior developer. You'll get back three concrete bugs, three specific strengths, and the ONE highest-impact change that would make this resume-grade.

Prefer the manual prompt? Open the AI tutor and paste this:

You are a senior Python code reviewer. I just wrote this for a Python
learning capstone. Review it as if I were applying for a junior Python
job. Tell me:

1. Three concrete bugs or risks (even if minor) — be specific, cite line
   numbers if possible.
2. Three things I did well that I should keep doing.
3. The ONE thing I should change to make this resume-grade.

Be direct. Don't be polite — be useful.

[paste my code below]

#Submit and share

You finished. You shipped a thing. The world doesn't know yet — fix that.

1. Push it to a fresh public GitHub repo. New repo, clean history, good README at the top.
2. Add the link to your portfolio at /portfolio/python (or wherever your portfolio lives). One line: "Python capstone — built X in N hours. [link]"
3. Post it to LinkedIn using this structure:

   I just built [X] with Python in [N] hours as my capstone project. It [does Y for Z users]. The thing that surprised me most: [one honest lesson]. Code + README here: [link]. Feedback welcome.

   Don't oversell. Don't underplay. Just describe what you did and what you learned. The honesty is what makes recruiters reach out.

4. (Optional) Reply to the QuizBlock below with what you built — the AI tutor will read it and give you a pat on the back, a frown, or a question you hadn't thought of.