Week 23 — Capstone I — Discovery and Architecture
A capstone brief, architecture design doc and shaped build plan
Ways of working: Swarms (applied)
Capstone · Thread A · System design #10
Domain pack: This is where your domain pack pays off: build the capstone on your own industry’s public data.
The capstone
Over four weeks you build one product end to end: discovery → prototype → data → AI → shipped → measured. It should combine at least:
- a user-facing app (Next.js)
- a backend/API with tests
- a data pipeline (Databricks or dbt) feeding analytics
- an AI feature with evals (LLM, RAG, agent or voice)
- production practices: flags, observability, a runbook and an experiment
Pick a theme from your own domain. See the domain packs for public datasets and capstone ideas in pharma and life sciences, healthcare, fintech and e-commerce. Some examples:
- Pharma: a drug-label Q&A and comparison tool over openFDA labels, with a pipeline tracking label changes, and evals for answer accuracy.
- Pharma: an adverse-event signal explorer over FAERS data: medallion pipeline, disproportionality stats, and an LLM that drafts plain-language signal summaries for review.
- Life sciences: a clinical-trial landscape explorer over ClinicalTrials.gov: site and sponsor analytics, plus an agent that answers protocol questions with citations.
- General: extend the course’s ticket service into an AI support co-pilot: triage, RAG answers, escalation analytics.
Use public or synthetic data only. Never use real personal or patient data.
1. Discovery sprint (~3.5 hrs) — swarm plus judgement
- Frame it using the week 3 format: problem, users, constraints, non-goals.
- Run an agent swarm. Use five parallel Claude sessions or subagents:
- competitive landscape
- user-pain hypotheses from public sources (forums, reviews)
- regulatory and compliance constraints
- technical feasibility spike (what’s hard?)
- a devil’s advocate
- Talk to at least 3 real people in the target role (or 5 simulated personas, clearly labelled).
- Synthesise into an opportunity solution tree. Pick one opportunity.
- Define success:
- a north-star metric
- 2 guardrail metrics
- the eval pass bar for the AI feature
- the experiment you’ll run in week 26
2. Architecture (~3 hrs)
Write capstone/docs/design.md, the full design doc:
- context and goals / non-goals
- a system diagram showing app, API, database, pipeline, AI, third parties, trust boundaries and sensitive-data flows
- the data model and pipeline (bronze/silver/gold)
- the AI design: model choice, prompts, tools, eval plan, cost and latency budget, fallbacks
- an API sketch
- observability: SLOs, dashboards, alerts
- security and compliance: a STRIDE summary, vendor BAA/DPA needs
- the cost estimate at pilot scale
- risks, and what you’ll cut first
Write ADRs for the 3–5 biggest decisions.
3. Shape the build (~1 hr)
Set an appetite of three weeks at about 8 hours each. Break the work into scopes (Shape Up style), and mark must-haves vs nice-to-haves. Produce:
- a “not doing” list
- an estimation sheet: your estimates now, with the actuals filled in later
4. System design #10 — capstone architecture review (~1 hr)
Present the design doc to Claude as a panel (staff SWE plus data engineer). Iterate on the doc until it survives the review.
5. Check
- What’s the single riskiest assumption in your capstone, and how will you test it first?
- Which component would you cut if you lost a week?
- Where does sensitive data flow in your diagram?
- What’s the AI feature’s eval pass bar, and why that number?
- What’s your cost per active user at pilot scale?
6. Teach-back
Write “How I chose my capstone: discovery with a swarm.”
Done when
- Discovery sprint done (swarm, conversations, opportunity tree)
- Success metrics defined
- Design doc and ADRs written
- Build shaped, with a “not doing” list
- Architecture review passed
- Teach-back written