Capstone Project
Required Output Classification
| Required output | Classification | Public/private guidance |
|---|---|---|
| Runnable project implementation and repository structure | Portfolio candidate | Polish the public repo only after tests pass, secrets are removed, and setup steps work from a clean checkout. |
| README with setup, inspection, verification instructions, and known limitations | Portfolio candidate | Make this public-facing if the project is safe to share; keep internal coursework notes in a private evidence folder. |
| Tests, traces, proofs, diagrams, benchmark outputs, or review notes required by the brief | Checkpoint evidence | Keep raw logs, benchmark runs, and reviewer comments private by default; publish summarized or reproducible versions when useful. |
| ADRs, design memos, runbooks, benchmark reports, and other high-effort engineering writeups | Portfolio candidate | These are worth polishing publicly when they tell a clear tradeoff story; otherwise keep them as private coursework evidence. |
| Final reflection, retrospective, or carry-forward notes | Checkpoint evidence | Keep candid self-assessment private unless rewritten as a concise public learning note. |
The capstone is one real, end-to-end system that you choose, scope, build, deploy, operate, and defend. It is the single graduation artifact of the degree. It is not a toy CRUD app and it is not a research paper -- it is a production-grade project that proves you can turn an ambiguous problem into a coherent engineering system, explain every non-trivial decision in writing, and walk a reviewer through how it runs, fails, and recovers. Work follows the weekly arc in Semester 10 -- Capstone Integration and each of its five modules in order.
Objective
Demonstrate end-to-end production readiness on one project you own entirely. By the end of week 96 you must be able to stand in front of a senior engineer and, without slides, explain the domain, the architecture, the deployment pipeline, the operational posture, and the tradeoffs -- and show working evidence of each. If any of the five dimensions (domain, implementation, deployment, operations, narrative) is missing or cannot be defended, the capstone is not complete.
Project Selection
Pick one project. Do not change it after week 91. The goal is a right-sized domain with a motivated problem and a defensible scope, as framed in Module 1's Problem Selection concept.
Constraints on choice:
- Must have at least two meaningfully distinct subsystems or bounded contexts (otherwise the architecture, ADRs, and deployment story become trivial).
- Must plausibly run in a real cloud account on a solo-operator budget.
- Must have a vertical slice that can be demoed in under five minutes.
- Must have a motivated user or scenario you can describe in one paragraph (not "an app for learning X").
- Must be finishable in six focused weeks with the scope-cut rules written in advance.
Example domain ideas (pick one or propose your own):
| Example | Why it works as a capstone |
|---|---|
| Bank-statement analyzer (upload PDF/CSV, categorize transactions, export insights) | Real ingestion, a parsing subsystem, a storage model, and a UI -- enough surface area for ADRs without blowing scope |
| Small conference-ticketing platform (tickets, check-in, organizer dashboard) | Forces consistency decisions (payments, inventory), clean bounded contexts, and an operational story for event day |
| Personal-finance aggregator (connect a sandbox provider, normalize accounts, show trends) | External integration, rate-limiting, caching, and an observability story around provider outages |
| Internal-tool registry (catalog of internal services with owners, health, runbook links) | Forces you to think about metadata, authz, and operability for the audience that reads your own runbooks |
| Niche SaaS for a concrete role (e.g., study-group scheduling for a specific cohort, invoicing for freelance translators) | Forces genuine requirements, not engineering fantasy; scope-cut rules bite earlier |
| MERN vertical slice with real domain workflow | Valid when it has authentication, API contracts, datastore decisions, tests, deployment, and operational evidence; the stack is not the achievement |
| E-learning system | Works if scoped to course authoring, enrollment, lesson progress, submissions, and instructor review with clear bounded contexts |
| Restaurant-management system | Works if scoped to reservations, table assignment, ordering, kitchen status, payment closure, and manager reporting |
| React portfolio plus service backend | Valid only when the portfolio is the product surface for real case-study evidence, not the whole capstone by itself |
| Express/API integration platform | Works if external API boundaries, error handling, rate limits, retries, and contract tests are first-class |
| AI assistant integration | Optional only with current APIs, privacy boundaries, cost controls, prompt/version tracking, and failure-mode tests |
If your idea cannot be described in one paragraph and cannot be reduced to a single vertical slice, it is not ready.
Mandatory Capabilities
Every capstone, regardless of domain, must demonstrate all of the following. Missing items block graduation.
- A working multi-service or meaningfully-structured system -- at minimum a modular monolith with clearly separated bounded contexts, a real datastore, and a real client surface (API, UI, or both).
- IaC-driven cloud deploy -- Terraform or equivalent, with state in a remote backend, reproducible from the repo by someone who is not you.
- CI/CD pipeline -- branch protections, automated tests on PR, deploy-on-merge to at least one environment, and a demonstrated rollback path.
- At least one observability signal wired end-to-end -- structured logs, a dashboard, or an SLO-backed alert that has actually fired once in testing.
- A written design -- one design doc plus at least three ADRs covering datastore, primary technology choice, and deployment topology (per Module 1 Cluster 4).
- At least one operational scenario walked through in writing -- a runbook entry for a realistic failure, exercised at least once (chaos tap, forced deploy failure, dependency outage simulated, etc.).
Option-Specific Requirements
If you choose one of the scaffolded project options above, add the matching evidence:
- MERN or Express/API projects: request/response contracts, auth flow, integration tests, seed data, error-handling matrix, and deployed API smoke tests.
- E-learning projects: course/module/lesson model, enrollment workflow, progress tracking, instructor review flow, and accessibility checks for learner screens.
- Restaurant-management projects: reservation/table/order/payment model, role permissions, kitchen-status workflow, reporting query evidence, and one concurrency or consistency note.
- React portfolio projects: case-study data model, screenshot/diagram pipeline, performance/accessibility checks, and a narrative that links each artifact to engineering evidence.
- AI assistant projects: current API usage note, data-retention policy, prompt boundary tests, cost estimate, fallback behavior, and human-review rule for risky outputs.
These options still require the mandatory capabilities above. A scaffolded domain does not reduce the bar for tests, deployment, architecture notes, runbooks, security review, or portfolio narrative.
Required Artifacts
- Domain model & bounded context -- One diagram plus a glossary of 10+ ubiquitous-language terms. Core subdomain is labeled, supporting and generic subdomains are identified and justified. See Module 1 Cluster 2.
- Architecture Decision Records (ADRs) -- At least three written ADRs with context, decision, alternatives considered, and consequences. Datastore choice, primary technology/framework choice, and deployment topology are mandatory. Additional ADRs for anything that surprised you during implementation.
- Implementation -- A working system in a single repo with a test pyramid (unit + integration + at least one end-to-end test), documented quality gates (coverage floor, linter, type-check), and a clean commit history. See Module 2.
- Infrastructure as Code -- Terraform (or CDK) root with module boundaries, remote state, and
plan/applyrunnable by a fresh clone. At least two environments (typicallystagingandprod, or a collapseddev+stagingplusprod). See Module 3. - CI/CD -- GitHub Actions (or equivalent) pipeline that builds, tests, and deploys on merge, uses OIDC to cloud, has a rollback path you have rehearsed with a timer, and produces release notes automatically. Link the pipeline in the README.
- Observability -- At least one dashboard and one SLO sketch with a numeric target, supporting alerts with a written rationale ("why would this wake me at 3am, and what do I do first"). See Module 4.
- Security review -- A one-page threat model following STRIDE or similar, a dependency-scan result, a secrets-handling write-up, and an IAM least-privilege note for the deploy role. See Module 4.
- Release / rollback plan -- A short deployment runbook: how you ship, how you verify, what the rollback trigger is, how long rollback takes, and who (future-you) is notified. Demonstrated end-to-end at least once.
Rubric (Self-Assessment)
Score each dimension honestly. A passing capstone averages 3+ with no dimension below 2. A distinction capstone averages 4+ with no dimension below 3.
| Dimension | What "good" looks like | Score (1--5) |
|---|---|---|
| Domain clarity | Problem stated in one paragraph; core subdomain is named and defended; glossary is used consistently in code, tests, and diagrams | |
| Architecture | Style matches top-3 characteristics; ADRs show real alternatives; C4 diagrams at Context/Container/Component; at least one fitness function runs in CI | |
| Engineering quality | Test pyramid present; quality gates enforced on PR; defect triage evident in commit history; code is readable without the author present | |
| Cloud & DevOps | IaC reproducible from clean clone; pipeline deploys on merge; rollback rehearsed; environment parity documented; OIDC not long-lived keys | |
| Operations | SLO with a target; at least one dashboard; one runbook entry exercised; one failure mode walked through; on-call triage steps written | |
| Security | Threat model with at least three realistic threats and mitigations; secrets never in repo; dependency scan clean or exceptions noted; least-privilege deploy role | |
| Communication | README orients a new reader in under five minutes; ADRs are reviewable; design doc is 4-8 pages and honest; 10-minute demo is coherent without slides |
Timeline (6 weeks)
The project is delivered in lockstep with the five modules of Semester 10. Module-internal week-by-week plans (especially Module 1's day-by-day for week 91) override this table.
| Week | Module | Capstone Milestone |
|---|---|---|
| 91 | Module 1 -- Domain Analysis & Architecture Design | Problem statement, risk register, MVP vertical slice defined, subdomain map, top-3 characteristics, style chosen, three ADRs drafted, C4 diagram set, 6-week plan with scope-cut rules, one fitness function in CI |
| 92 | Module 2 -- Implementation & Testing | Walking skeleton deployed through the full pipeline (even if it only returns hello world), vertical slice implemented end-to-end, unit + integration tests for the core subdomain, quality gates enforced on PR |
| 93 | Module 3 -- Cloud Deployment & CI/CD | IaC root covers all environments, pipeline builds/tests/deploys on merge via OIDC, rollback rehearsed with a timer, release notes automated, smoke tests run post-deploy |
| 94 | Module 4 -- Operational Readiness & Security Review | SLO drafted with numeric target, dashboard live, at least one alert configured with rationale, threat model written, one runbook entry exercised against a forced failure, dependency scan clean or documented |
| 95 | Module 5 -- Portfolio & Specialization Assessment | Case study written (problem -> approach -> outcome -> tradeoffs), portfolio page updated, specialization decision drafted with 12-month plan, demo script rehearsed |
| 96 | Final verification | Exam taken, checkpoint gate walked, 10-minute demo + defense recorded, known-limitations and future-work sections written, repo frozen |
If any week slips, apply the pre-committed scope-cut rules from Module 1. Do not extend the semester.
Demo & Defense Prep
The defense is a 10-minute walkthrough followed by questions, without slides. Rehearse it in week 95 and again at the start of week 96.
10-minute demo script (target shape):
- Minute 0-1 -- Problem and user. One sentence each. What is the domain, who is the user, what is the outcome.
- Minute 1-3 -- Architecture at a glance. Open the Container diagram. Walk the vertical slice from client to datastore. Name the core subdomain. Name one ADR and why you made that call.
- Minute 3-5 -- Live demo of the vertical slice. Use the deployed environment, not localhost. Show the happy path end-to-end.
- Minute 5-7 -- Production posture. Open the dashboard. Point at the SLO. Describe what the alert does. Reference the runbook entry.
- Minute 7-9 -- Pipeline and rollback. Show the CI pipeline on a recent merge. Describe the rollback trigger and the rehearsed rollback time.
- Minute 9-10 -- Honest limitations. Name two things you cut, one thing you would redesign, and what week-7 would have bought you.
Anticipated questions (prepare written answers in advance):
- "Why this architecture style and not the one-step-up or one-step-down alternative?"
- "What breaks first under load, and how would you know?"
- "Walk me through a bad deploy -- how do you detect it, how fast do you roll back, and what is lost?"
- "Where is your consistency boundary, and what happens if it is violated?"
- "What is your single biggest piece of technical debt, and why is it acceptable?"
- "What would the second version of this system look like?"
- "What did you cut, and what was the rule that told you to cut it?"
- "Which semester's material did you lean on hardest, and which did you barely touch?"
Record the rehearsal. Listen back. If a question lands that you cannot answer in under 30 seconds, write the answer down before the real defense.
Submission Checklist
- Repository (public or private) with access instructions for the reviewer in the top-level README, including a one-command local run and a link to the deployed environment or demo video.
- One-page executive summary (
library/raw/summary.mdor equivalent) -- problem, who it is for, architecture in one diagram, status, and the single most interesting tradeoff you made. - Known limitations and future work section in the README or design doc -- honest, specific, and written in the first person ("I did not implement X because Y; the next step would be Z").
Production-Style Project Brief
Use this project as a reviewable engineering brief, not only a completion exercise.
Problem statement
Write a one-paragraph statement covering the user, the problem, the constraint, and the outcome this project is meant to produce.
Required evidence
- working artifact or reproducible deliverable
- README with setup, inspection, and verification instructions
- tests, traces, proofs, diagrams, benchmark output, or review notes appropriate to the semester
- decision log with at least three meaningful tradeoffs
- known limitations section with explicit scope cuts
Review questions
- What is the smallest vertical slice that proves the project works?
- Which requirement is most likely to be misunderstood by a reviewer?
- What did you deliberately not build, and why?
- What evidence would convince someone else that the result is correct?
Done means
The project is done only when another technical reader can inspect the artifact, run or review the verification evidence, and understand the tradeoffs without a live explanation.
Weekly Project Milestones
Use these milestones to keep the project from becoming a last-week scramble.
| Milestone | Focus | Evidence |
|---|---|---|
| Start | Scope the smallest useful slice | problem statement, non-goals, first task list |
| Early build | Produce a walking version | runnable skeleton, first test, first committed artifact |
| Middle | Add the hard part | implementation note, trace/proof/benchmark/design decision |
| Review | Stress the weak point | failure case, debugging note, peer/self review, correction commit |
| Finish | Package for inspection | README, verification instructions, known limitations, reflection |
Answer-Quality Examples
| Quality | What it sounds like |
|---|---|
| Weak | "I built it because the module asked for it." |
| Acceptable | "It works for the required examples and I can explain the main idea." |
| Strong | "Here is the tradeoff I chose, the evidence that supports it, and the case where it would fail." |
| Portfolio-ready | "A reviewer can inspect the artifact, rerun the checks, and understand why this solution fits this semester's goals." |
Future Capstone Connection
Before closing this project, write two sentences on how it could help the final capstone: one reusable technical skill and one artifact habit to preserve.
Calibration Materials
Use these learner-visible calibration materials before self-grading or requesting review: