Skip to content

01. Week 15 — Capstone Project

What this module must prove

By Sunday, your project should demonstrate: - Clear product scope and target user. - A written system design with contracts between components. - One working end-to-end path. - A first-pass eval suite that catches system failures. - Latency and cost visibility. - A believable deployment path. - A portfolio story worth showing recruiters and hiring managers.

Capstone scope guardrails

Good scope

  • One use case.
  • One primary user persona.
  • One measurable success definition.
  • Four to six meaningful components.
  • Two weeks of believable effort.

Bad scope

  • Full platform ambitions.
  • Three unrelated features.
  • Multi-agent for prestige only.
  • No eval plan.
  • No path to demo.

Deliverables before Module 16

  • [ ] Problem statement and target user locked.
  • [ ] Architecture diagram drawn.
  • [ ] API / component contracts written.
  • [ ] MVP demo works on one happy path.
  • [ ] First system eval suite exists.
  • [ ] Latency and cost budget exists.
  • [ ] README skeleton exists.
  • [ ] Module review completed.

🧠 Mental models

  • System design: "draw the blueprint before pouring concrete"
  • One end-to-end path: "prove one train line runs before adding more stations"
  • Eval suite: "building inspection, not demo applause"
  • Deployment path: "plan move-in day, not just construction photos"
  • Scope control: "one sharp spear, not a bag of gadgets"
  • Observability: "dashboard gauges that tell you the engine is failing before smoke appears"

⚠️ Common traps

  • Trying to impress with too many personas or features instead of one defensible user workflow.
  • Building components in isolation and discovering too late that the full request path is slow or brittle.
  • Shipping a demo without an eval suite that catches retrieval misses, tool failures, or hallucinated outputs.
  • Ignoring latency and cost until the last week, when architecture changes become expensive.
  • Adding agent loops or multi-agent coordination for prestige instead of clear product need.
  • Presenting diagrams without a believable deployment, rollback, and operations story.

🔗 Prerequisites & connections

Builds on: Modules 00-14 across models, prompting, RAG, agents, evals, reasoning, multimodal systems, and diffusion.

Feeds into: Module 16 engineering principles, where your capstone trade-offs become explicit lessons about reversibility, quality gates, and technical leadership.

💬 Interview phrasing

  • What is the smallest version of your capstone that still proves user value?
  • Where can the system fail end to end even if each individual component looks healthy?
  • Why did you choose this architecture instead of a simpler pipeline or a more agentic one?
  • What metrics told you the project was ready to demo or deploy?
  • If you had to cut half the scope tomorrow, what would remain and why?

⏱️ Difficulty markers

  • 🟢 MVP scoping
  • 🟡 component contracts
  • 🟡 end-to-end integration
  • 🟡 first-pass eval suite
  • 🔴 deployment and rollback design
  • 🔴 balancing quality, latency, and cost across the full system

Health check questions

  1. If traffic doubled tomorrow, what breaks first?
  2. If the model got slower tomorrow, how would users feel it?
  3. If retrieval fails, what does the system do instead?
  4. If an interviewer asks "why this architecture," can you defend it clearly?
  5. If Module 16 forced you to cut half the scope, what would remain?

Bridge to Module 16

Next module — 20_engineering_leadership_judgment — formalizes the engineering judgment you developed here into principles: how to make technical decisions, manage complexity, and lead AI teams.