Capstone Projects#

Day 13–15 · Where reading turns into shipping

The first eight chapters were about absorbing. This chapter is the inverse - output. You pick a capstone, you build it under mentorship, you demo it, and the result is the artifact your buddy and your manager will use to judge whether you're ready for the first real customer engagement.

A bootcamp without a capstone is a course. A bootcamp with one is a credentialing system.

---

TL;DR#

• What - A self-directed, mentor-reviewed project that integrates the bootcamp.
• Time - 3 days (Days 13–15), unless your buddy approves a stretch.
• Format - Ship something runnable + a 30-minute demo + a 2-page write-up.
• Evaluation - Buddy + one senior reviewer. Pass / iterate.
• Output - A repo, a live URL (if applicable), and a public record of judgment calls you made.

---

What "capstone" means here#

Not a class project. Not a portfolio piece. The capstone is calibrated to the work you'll do on Day 16 and after: integrating real systems, making real judgment calls, shipping something that solves a real problem under real constraints (time, code review, customer expectations).

Three principles:

1. Real, not toy. The project should solve a problem you've actually noticed. Toy projects produce toy learning.
2. End-to-end, not partial. You'll touch schema → backend → UI → deploy. No "I'll do the frontend later." That's the chapter we're testing.
3. Documented for a stranger. The README must be sufficient for someone new to clone, run, and understand the project. Write for the engineer who joins Welzin three months after you.

How to pick#

Use this checklist:

• Does it integrate at least three chapters of the bootcamp? (E.g., Full Stack + Databases + CI/CD.)
• Can you finish a v0.1 in 3 days of focused work?
• Could the work be shown - a live URL, a demo command, a screenshot?
• Would your buddy be willing to code-review it without losing a Saturday?
• Is there a clear "ship criteria" you'd defend in a stand-up?

If all five answers are yes, that's a candidate.

Six capstone tracks#

Pick one. Or propose your own and your buddy will sanity-check it.

1. Customer Notes - full-stack, end-to-end#

Build a "Customer Notes" web app. List + detail page. Email-magic-link auth. Postgres-backed. One LLM-powered feature (auto-summarise a note). Deployed to Vercel with a live URL.

Touches: Full Stack, Databases, CI/CD, AI/ML. Why it's a great capstone: It's the slice every Welzin customer engagement needs - auth, CRUD, an AI feature, deploy pipeline. You'll hit every chapter's lessons in order.

2. A real Claude Skill - and ship it#

Identify a multi-step task you've done twice already this bootcamp. Author it as a Claude Code skill in .claude/skills/. Add it to a shared plugin repo. Write the test plan in the description. Get one other engineer to use it without coaching.

Touches: Linux, Git, Claude & Skills. Why it's a great capstone: The skill becomes a permanent part of how the team works. It compounds.

3. A meaningful OSS contribution#

Pick a project from Chapter VIII. Find a real bug or gap. Open the issue. Open a PR. Cycle through review. Get it merged.

Touches: Open Source, Git, plus whatever the project's stack is. Why it's a great capstone: Your name is on a public commit log. The PR review is a graded conversation with a stranger - exactly the muscle a forward deployed engineer needs.

Important: This is not a typo fix. The bar for "meaningful" is your buddy's call.

4. A small RAG over Welzin docs#

Ingest the internal Welzin engineering docs + this bootcamp. Build a small RAG over them with semantic chunking, hybrid retrieval, a re-ranker, and citations. Ship a simple chat UI. Run a 20-question eval and publish the score.

Touches: AI/ML (RAG sub-chapter), Databases (pgvector or Qdrant), Full Stack. Why it's a great capstone: This is the single most-requested feature shape in current Welzin sales calls. Real RAG with evals - not a hack-day demo - is a high-signal artifact.

5. An MLOps mini-stack#

Train a small classifier (anything tabular - churn, default, anomaly) end-to-end. Track it in MLflow. Serve it via KServe on a kind cluster. Add Prometheus + Grafana for inference metrics. Document the runbook.

Touches: AI/ML, DevOps, Databases, CI/CD. Why it's a great capstone: The MLOps loop is theoretical for most fresh grads. Doing one end-to-end - even small - converts theory to instinct.

6. Replicate a customer-deploy pattern#

Pick one of Welzin's customer deployment patterns (your buddy will share a redacted version). Replicate it from scratch on your own VMs / cluster. Document the gotchas. Write the runbook your future-self will use the first time you do this for real.

Touches: Linux, DevOps, CI/CD, plus AI/ML if the deploy includes inference. Why it's a great capstone: It's the closest possible simulation of the actual job.

Mentorship model#

• Day 13, AM - pitch your capstone to your buddy in writing. One page: what, why, ship criteria, risks. Buddy says yes / refine / pick something else.
• Day 13–15 - work. Stand up daily for 15 minutes; share where you're stuck.
• Day 15, PM - demo + review.

Your buddy is not a co-worker on the project. Their job is to course-correct, not to ship for you.

What "done" looks like#

A capstone is "done" when:

• You can demo it in 30 minutes including a live failure mode.
• The README is sufficient for someone you don't know to reproduce the result.
• You can answer: what's the failure mode I'd lose sleep over? - and you've mitigated it or documented it.
• Your buddy reviewed the diff (or the commit log) end-to-end.
• You wrote a 2-page postmortem covering: what you'd do differently, what surprised you, what you'd build next.

The postmortem is the most valuable artifact. It's the document your manager will refer back to in your first 90-day review.

Hands-on Checkpoints#

• Read the six tracks above. Rank them by personal interest.
• Talk to your buddy about which track matches the team's current needs.
• Write the one-page pitch (problem, approach, ship criteria, risks).
• Get buddy approval.
• Ship. Demo. Postmortem. Mark complete only after all three.

Further reading#

• [Welzin onboarding handbook (internal)] - your buddy will share the link.
• How to write a postmortem - Google SRE book chapter, free online.
• Drew DeVault - How to write a project README (and his other writing on this) - for the README discipline.

Welzin opinion: The capstone is not graded. It's signalled. The signal we look for is judgment under constraint - what you cut, what you kept, what you can defend. Build something you'd put on the internet with your real name on it.