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 mentor-reviewed project that integrates the bootcamp. Track 0 (a simulated client engagement) is the recommended default; six self-directed tracks follow.
• 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.)
• Does it exercise Client Engineering - a spec you extracted rather than received, and an agreed definition of done? (Track 0 is built around this; bolt a client frame onto any other track to get it.)
• 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.

Seven capstone tracks#

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

0. The client engagement - recommended default#

Your buddy plays a customer with a vague, real-shaped problem and does not volunteer requirements. Run the full engagement in three days: a 30-minute discovery interview on Day 13 producing a confirmed one-pager, an acceptance eval agreed before you build, a working slice built against messy sample data, a mid-point demo on Day 14, and a handoff doc plus final demo on Day 15. Your buddy stays in character throughout, including changing their mind once.

Touches: Client Engineering primarily, plus whichever chapters the build needs (usually Full Stack, Databases, AI/ML).

Why it's the recommended default: every other track tests whether you can build. This one tests the thing that actually decides whether an engagement succeeds - can you extract a spec from a person, agree what "done" means in numbers, absorb a scope change without silently slipping, and hand over something a stranger can operate. The code can be modest. The judgment cannot.

Extra ship criteria for this track:

• A one-pager the "customer" confirmed in writing, including an explicit out-of-scope list
• An acceptance eval of at least 20 real-shaped cases with an agreed passing bar, plus a measured baseline
• A written weekly status in shipped / next / blocked / risk form, containing at least one piece of honest bad news delivered with options
• A "where does our data go?" answer, one page, covering endpoints, storage, retention, and PII handling
• A handoff doc a stranger could operate the system from

Note for self-study: if no buddy is available, write the brief yourself for a business you know well, then answer your own discovery questions in that person's voice. Adversarial honesty is the whole exercise - if you never get told "that is not what I asked for", you are grading yourself too kindly.

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 the optional Open Source chapter. 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 seven tracks above. Rank them by personal interest, and default to Track 0 unless you have a reason not to.
• 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.