Appendix D — Fifty Capstone Ideas, Sized

“For whoever has despised the day of small things shall rejoice…” — Zechariah 4:10 (ESV)

D.0 — How to Use This Catalog

Read this section before you read a single idea. It is the difference between this appendix helping you and this appendix wrecking your semester.

This is a generator, not a menu. You are not here to shop. You are here to prime a pump that has gone dry. In Chapter 2 you have to arrive at three genuine candidates, screen them, score them, kill two, and defend the survivor in a memo a stranger could check line by line. Nothing in this appendix does that work for you. What it does is break the blank page — and a blank page is the only problem it solves.

Understand what happens if you adopt an entry wholesale. Every one of these fifty is written with a type of user, not a person. The evidence gate in Chapter 2 asks you to name a human being, give the date you talked to them, and quote them three times. You cannot do that for a user I invented. So an entry taken straight off this page walks into Week 2 already failing the highest-weighted criterion on the scorecard, and it walks into Week 16 with a presenter who cannot answer the first question a panel asks: why this? “It was number 34 in the appendix” is a bad answer, and you will hear yourself say it.

Here is what the catalog is actually good for.

Use 1 — Break the freeze. Read a whole section fast, do not evaluate, and notice which entries make you think “oh, I know someone with that problem.” That reaction is the only signal here worth anything. Chase the person, not the entry.

Use 2 — Steal the shape, not the subject. Entry 15 is a flaky-test detector. The shape is: ingest boring machine output over time, compute a statistic nobody currently computes, put it where a decision gets made. That shape fits fifty problems that have nothing to do with tests. Shapes transfer. Subjects do not.

Use 3 — Calibrate on the “hard part” line. Every entry names the one thing that will eat the schedule. Read thirty of those lines in a row and you will start to recognize the genus: concurrency and state machines, messy real-world input, evaluation with no ground truth, reliability over weeks, and human process. Then look at your own idea and ask what its hard part is. If you cannot name one, your project is a set of forms over a database and it will not survive Week 16’s “what was hard?” — which is the question that separates a capstone from a homework set.

Use 4 — Rehearse the cut. Each entry gives one way to shrink and one way to grow. That is the exact move Chapter 2 demands of you, done fifty times where the stakes are zero. Practice the move here so your hand is steady when it is your own project on the table.

How to read an entry

What the hour numbers mean, and what they do not

Every MVS is sized at roughly 40 to 48 hours of net feature construction — the number Chapter 2 derives from the 240-hour budget after inception, requirements, design, planning, review, documentation, deployment, and delivery are paid for. Add the walking skeleton, continuous integration, and deployment plumbing and each of these lands near the 60-to-75-hour construction ceiling. That is deliberate. These are sized to fit, not to impress.

Now the caveats, and they matter more than the numbers.

• My estimate is for a generic senior with a novelty load of at most two. If three of the technologies in an entry are new to you, multiply the construction figure and then cut until it fits. Novelty load is the single best predictor of a capstone overrunning, and it is the number I cannot know about you.
• A “slice” is a vertical slice — interface, handler, data access, validation, the error path, at least one test, and the documentation line. Not the happy path in an editor.
• These numbers are an outside view. Run the 240-Hour Scope Sizer on the page for Chapter 2, then estimate your chosen scope bottom-up by hand, and reconcile the two. Two independent estimates that agree within about thirty percent give you a defensible number. My figure in this appendix is a third opinion from someone who has never met you.

Three things this catalog deliberately refuses to do

It does not promise you any data. Where an entry needs a feed, a corpus, an API, a device, or somebody’s records, that is a dependency you must exercise for real — one live call, one saved response, one dated note about the rate limit and the terms — before the idea becomes a candidate. Availability, license terms, and free tiers change without notice and without telling you. The Get gate is yours to run, every time, and it is where quiet capstone deaths happen.

It does not name products you must use. Every entry is written in terms of capabilities — a message queue, a speech model, an SMS gateway, an embedding model, a microcontroller — because this course is stack-agnostic and because a vendor named in a book is a vendor whose terms have already changed by the time you read it. You pick, you verify, you defend it in an architecture decision record in Week 5.

It does not invent interfaces. You will not find an endpoint or an SDK call anywhere in these fifty entries, because I will not hand you a plausible-looking thing that does not exist. Assistants will. Verify every dependency an assistant proposes the same way you verify mine: by calling it.

Coach’s Note — Draw your three Week-2 candidates from three different sections of this appendix. Ideas from one domain share one blind spot, and you will not see it, because it is the blind spot. Three domains force three different failure modes into the open, which is the entire point of running three candidates.

A field guide to the domains

D.1 — Web and Mobile Applications

The trap in this domain is that the forms are easy and the state is not. Pick a project whose difficulty lives in the model, not in the markup.

1. Shift Swap Board

• Problem / user. Hourly student workers at a dining hall, library desk, or campus store trade shifts in a group chat. Nobody can tell what is actually covered, and the manager rebuilds the week from screenshots every Friday.
• MVS — “Post, claim, confirm” (5 slices, ≈43 h). Post a shift you need covered; browse open shifts; claim one; manager confirms or rejects; a read-only current-week coverage view. Team join code instead of accounts.
• Hard part. The state machine and the race. A shift is posted, claimed, contested, confirmed, or expired, and two people will claim the same shift two hundred milliseconds apart. Getting that right — and provably right, under a concurrent test — is the project.
• Stretches. Data modeling, optimistic concurrency control, authorization scoping, transactional thinking, and writing acceptance criteria for behavior you cannot see.
• Smaller. One team, manager-only confirmation, first-write-wins on claims with the loss shown honestly in the interface.
• Bigger. Calendar export and a full audit trail of every state transition, with a written, defended conflict-resolution policy.

2. Lending Locker

• Problem / user. A student organization, makerspace, or media lab lends out cameras, tools, or test equipment on a paper clipboard. Items disappear, and nobody can answer “who had it last?”
• MVS — “Out, in, overdue” (5 slices, ≈41 h). Item catalog with condition notes; check out with a due date; check in with a condition update; an overdue list; a per-item history page.
• Hard part. Partial and wrong returns. Kits come back incomplete, items get returned by someone who did not check them out, and two people swear they returned the same tripod. The reconciliation model — and the correction workflow that leaves an audit trail — is where the hours go.
• Stretches. Domain modeling, event-sourced thinking, report generation, designing for correction rather than perfection, and handoff documentation for non-technical volunteers.
• Smaller. Single-item checkout only, no kits, no condition tracking; overdue is a list, not a notification.
• Bigger. Reservations with a calendar, plus a fair queue when demand exceeds supply — and a written policy defending the fairness rule you chose.

3. Trail Steward Field Reports

• Problem / user. Volunteer trail or park stewards report downed trees, washouts, and sign damage by texting photos to a coordinator, who retypes them. Half the reports arrive with no location, and there is no signal where the problems are.
• MVS — “Report offline, sync later” (5 slices, ≈46 h). Capture a report with photo, category, severity, and device location while offline; a local queue; sync on reconnect; a coordinator map and list; status changes to resolved.
• Hard part. Offline-first correctness. A queued report must survive an app restart, a dead battery, and a sync that half-fails, without duplicating or silently dropping anything. Conflict handling and idempotent upload will eat more of the schedule than the map.
• Stretches. Client-side storage, sync protocol design, idempotency keys, image handling and size budgets, and testing a network you have to fake.
• Smaller. Online-only submission with a clear “you are offline” state; no photos, or one photo with a hard size cap.
• Bigger. Duplicate detection so five people reporting the same fallen tree produce one item, with a defended similarity threshold.

4. Intramural League Runner

• Problem / user. A campus intramural coordinator builds a season on a whiteboard and a spreadsheet, then spends the semester fielding “when do we play?” emails and rescheduling rained-out games by hand.
• MVS — “Season, schedule, standings” (5 slices, ≈45 h). Teams and divisions; generate a round-robin schedule against court and time-slot availability; record results; standings with a stated tiebreak rule; a public read-only schedule page.
• Hard part. Scheduling with real constraints. Courts, referees, teams that cannot play Tuesdays, and no double-headers turns a tidy round-robin into a constrained assignment problem that gets ugly fast. You will need a defensible heuristic and an honest account of when it fails.
• Stretches. Constraint modeling, greedy and backtracking search, algorithmic complexity in practice, and explaining a heuristic’s limits in writing.
• Smaller. One division, one venue, fixed weekly slots, manual rescheduling by dragging a game to an open slot.
• Bigger. A rescheduling engine that repairs a season after cancellations while minimizing disruption, with the objective function written down and defended.

5. Split the House

• Problem / user. Roommates, a travel group, or a small team front money for each other and settle up badly — a chat thread of numbers, one person quietly absorbing the difference, and a slow accumulation of resentment.
• MVS — “Ledger and settle-up” (5 slices, ≈42 h). Record an expense with an uneven split; a running per-person balance; a settle-up suggestion that minimizes the number of transfers; edit and void with history preserved; an export.
• Hard part. Money and graphs. All arithmetic in integer minor units, never floats; every correction as a reversing entry rather than an edit; and the settle-up itself is a debt-simplification problem on a graph where the obvious greedy answer is not always minimal.
• Stretches. Exact decimal arithmetic, immutable ledger design, graph algorithms, invariant testing with generated cases, and internationalization if you allow more than one currency.
• Smaller. Equal splits only, no editing after entry (void and re-enter), single currency.
• Bigger. Multi-currency with dated rates from a source you have verified, plus a proof-by-property-test that the ledger always balances.

D.2 — Data and Analytics

Get the data in Week 2 or do not choose the project. An analytics capstone with no data in Week 9 is a capstone with no capstone.

6. Transit Reliability Report Card

• Problem / user. Riders of one bus or rail line believe it is unreliable and have nothing but anecdote. Nobody can say how unreliable, at which stop, at what hour.
• MVS — “One line, one semester” (5 slices, ≈46 h). Ingest the agency’s published schedule; poll its real-time feed on a schedule if one exists; store observations; compute on-time performance by stop and hour; one report page with a stated methodology.
• Hard part. Matching observation to intent — deciding which scheduled trip a given vehicle observation belongs to when the feed is ambiguous, and then defining “on time” in a way you can defend when the agency’s own definition differs from yours.
• Stretches. Long-running ingestion, idempotent writes, time zones and daylight saving, statistical summarization, and methodological honesty in a written report.
• Smaller. Schedule-adherence analysis over a static feed plus manually collected observations at one stop for two weeks. Smaller, and often more honest.
• Bigger. Multiple lines with a comparison, plus a documented weather and event overlay drawn from a public source whose terms you have read.
• Before you commit: confirm your agency actually publishes what you need, in a format you can parse, under terms that permit this. Many do; assume none do until you have made the call.

7. Cash Flow Cruncher

• Problem / user. A sole proprietor — a barber, a food truck, a contractor — exports transactions from their bank and their bookkeeping tool and has no idea whether payroll clears in six weeks.
• MVS — “Import, categorize, project” (5 slices, ≈45 h). A CSV importer with a column-mapping step; rule-based categorization with manual override; a thirteen-week rolling projection; a variance page comparing forecast to actual; an export.
• Hard part. Real exports are filthy. No two agree on columns, dates arrive in four formats, refunds are negative amounts sometimes and separate rows other times, and re-importing an overlapping range must not double-count. Idempotent ingestion and a deduplication rule you can defend will eat the schedule.
• Stretches. Parsing and normalization, exact money handling, rules engines, deduplication strategy, and building a data pipeline you can rerun safely.
• Smaller. One fixed export format, categorization by keyword rules only, a four-week projection.
• Bigger. Scenario modeling — “what if this invoice pays thirty days late” — with the assumptions visible on the page rather than buried in code.

8. Weather-Normalized Building Energy Report

• Problem / user. A facilities manager, a church trustee, or a small landlord has years of utility bills and cannot tell whether last winter’s spike was the new tenant or the cold.
• MVS — “Normalize and compare” (5 slices, ≈43 h). Ingest historical bills; join to daily temperature data from a public source you have verified; compute degree-day-normalized usage; a period-over-period comparison; a one-page report the owner can hand to a board.
• Hard part. Making the normalization defensible. Choosing a base temperature, handling billing periods that do not align to months, and knowing whether a change is real or noise — a modeling and statistics problem wearing an ordinary dashboard.
• Stretches. Time-series alignment, regression fundamentals, uncertainty communication, data provenance, and writing findings for a non-technical decision maker.
• Smaller. One building, one meter, monthly resolution, a fixed base temperature stated as an assumption.
• Bigger. Change-point detection that flags when a building’s consumption behavior shifted, with the method and its false-positive rate reported.

9. Pick-Path Analyzer

• Problem / user. A small fulfillment operation — a campus bookstore, a food pantry warehouse, a two-person e-commerce shop — arranged its shelves by category years ago and walks miles a day because of it.
• MVS — “Measure, model, propose” (5 slices, ≈47 h). Ingest historical order lines; compute item co-occurrence; a travel-distance model for the current layout; a proposed re-layout; a simulation reporting expected pick time before and after.
• Hard part. Credibility. A simulation nobody can check is a screensaver. You must calibrate the travel model against pick times you actually time with a stopwatch, and report the gap between simulated and observed honestly.
• Stretches. Association analysis, clustering, discrete simulation, model validation, and the discipline of reporting a result that undercuts your own recommendation.
• Smaller. Analysis and a ranked co-location recommendation with no simulation — validated by timing ten real picks before and after moving five items.
• Bigger. A constrained optimizer respecting shelf capacity, weight limits, and cold storage, with the objective and constraints written up as a specification.

D.3 — Machine Learning and Applied AI

The rule for this whole section: no baseline, no project. If you cannot show your model beats the dumbest reasonable alternative on a held-out set, you have a demo, not a result.

10. Helpdesk Triage Assistant

• Problem / user. A nonprofit or department shared inbox where volunteers hand-route several hundred messages a week, badly, and the same question gets answered four different ways.
• MVS — “Suggest, never send” (5 slices, ≈45 h). A labeling tool; a labeled corpus you build yourself; a baseline classifier; a routing suggestion surfaced to a human who confirms or overrides; an evaluation harness with a held-out set, a confusion matrix, and per-class precision and recall.
• Hard part. Labels and imbalance. Your own labels will be inconsistent until you write a labeling guide, three of your categories will have twelve examples each, and accuracy will look wonderful while the model never predicts the class that matters. Building an evaluation that reflects the deployed decision is the work.
• Stretches. Annotation methodology, class imbalance, threshold selection, human-in-the-loop interface design, and data governance.
• Smaller. Three categories instead of twelve, keyword baseline only, evaluation on a hand-held-out week.
• Bigger. Active learning — the tool asks a human to label the examples it is least sure about — with a measured reduction in labeling effort.
• Before you commit: those messages belong to the organization and contain other people’s information. Get written permission, redact before you store, and put the retention rule in your specification.

11. Field Recording Call Spotter

• Problem / user. A birding club, a herpetology lab, or a county naturalist leaves recorders in the field and has hundreds of hours of audio nobody will ever listen to.
• MVS — “Record, label, detect” (5 slices, ≈47 h). A labeling interface over spectrogram segments; a corpus you record and label yourself; a detector for three to five target calls; event-level evaluation; a review queue where a human confirms detections.
• Hard part. Evaluation on events, not frames. A detector that is ninety-nine percent accurate frame-by-frame can miss every call, because calls are rare. You must define an event, define a hit, choose a tolerance window, and report precision and recall at an operating point you can justify.
• Stretches. Signal processing, spectrogram features, weak and noisy labels, imbalanced detection metrics, and annotation tooling.
• Smaller. Two target calls, a fixed detection threshold, evaluation on one hour of hand-labeled audio.
• Bigger. On-device detection on a battery-powered recorder, with a measured accuracy-versus-power tradeoff.

12. Grounded Answers Over a Manual You Own

• Problem / user. A maintenance team, a student org, or a small agency has a few hundred pages of procedure documents. Nobody reads them; everybody asks the one person who does.
• MVS — “Cite or refuse” (5 slices, ≈46 h). Chunking and indexing over a corpus you have the right to use; retrieval; answer generation with inline citations to the source passage; an explicit refusal path when retrieval is weak; a sixty-question gold set with graded answers.
• Hard part. Evaluation and refusal. The failure mode is confident wrongness, and the only defense is measurement: retrieval quality at a fixed cutoff, a groundedness check that every claim traces to a retrieved passage, and a threshold where the system says I do not know. Building that gold set is unglamorous and it is the project.
• Stretches. Retrieval systems, embedding and chunking tradeoffs, evaluation design, prompt contracts, cost and latency budgeting, and honest failure reporting.
• Smaller. Retrieval only — return the three most relevant passages with no generation. Genuinely useful, fully evaluable, and half the risk.
• Bigger. A comparison of two retrieval strategies on the same gold set with a stated significance test, written up as a short technical report.

13. Demand Forecast for a Small Operation

• Problem / user. A coffee cart, a campus bakery, or a food pantry over-produces on slow days and runs out on busy ones, and the manager forecasts with a feeling.
• MVS — “Beat the naive baseline” (5 slices, ≈41 h). Ingest historical sales; a seasonal-naive baseline; one forecasting model; rolling-origin backtesting; a one-week forecast page showing intervals, not just a line.
• Hard part. Beating the baseline honestly. Most student forecasting projects never establish that their model outperforms “same day last week,” because leakage in the backtest inflates every number. Getting the evaluation protocol right is more work than getting the model right.
• Stretches. Time-series validation, leakage avoidance, prediction intervals, metric selection, and communicating uncertainty to someone who wants a single number.
• Smaller. Baseline plus one model, single location, single product family, evaluation on a fixed final holdout.
• Bigger. Incorporate an external regressor — weather, the academic calendar, event schedules — from a source whose terms you have verified, and quantify whether it actually helped.

14. On-Device Sorting Classifier

• Problem / user. A recycling coordinator, a parts room, or a lab needs a fast visual call — is this item category A or B — made by people who guess and get it wrong.
• MVS — “Collect, fine-tune, deploy small” (5 slices, ≈48 h). Collect and label roughly fifteen hundred of your own images; fine-tune a small pretrained model; export to an edge or mobile runtime; measure accuracy and latency on the target device; a capture-and-classify interface with a confidence display.
• Hard part. Distribution shift and the silent export. Your clean well-lit training photos are nothing like the loading dock, and quantizing for the device can quietly cost you accuracy you never re-measure. The project is the evaluation on-device, in situ, not the training curve.
• Stretches. Dataset construction, transfer learning, model export and quantization, latency profiling, and designing an interface that communicates uncertainty rather than hiding it.
• Smaller. Two classes, a fixed capture rig so lighting is controlled, evaluation on a laptop instead of the device.
• Bigger. A rejection class with a calibrated confidence threshold, so the system declines rather than guesses, plus a measured accuracy-versus-coverage curve.

D.4 — Developer Tooling

You are a real user here, which is a gift and a trap. The gift is fast feedback. The trap is a user base of one — so name a second user in Week 2 and get them to try it in Week 12.

15. Flaky Test Detector

• Problem / user. A team whose continuous integration reruns until green. Everyone knows some tests are flaky; nobody knows which, or how much they cost.
• MVS — “History, rate, quarantine” (5 slices, ≈43 h). Ingest standard test-result XML across builds; store history keyed to commit; compute a per-test flakiness rate; emit a report and a quarantine list; run as a step in whatever CI you use.
• Hard part. Attribution. Between two runs the code changed, so a failure might be a flake or a genuine break. You need a definition of flakiness that survives a moving codebase — same commit, different outcomes is a start, and it is rarer than you think.
• Stretches. Parsing and schema tolerance, time-series over build data, statistical thresholds, CI integration, and command-line interface design that fits an existing workflow.
• Smaller. One test framework’s output format, one repository, a report file instead of a CI gate.
• Bigger. Automatic bisection to the commit where a test began flaking, with the search strategy and its cost documented.

16. Migration Safety Linter

• Problem / user. Any team that has taken production down with a schema migration during business hours — which is most of them, once.
• MVS — “Parse, classify, block” (5 slices, ≈44 h). Parse migration files; classify operations as safe, locking, destructive, or irreversible for one database engine; flag column drops still referenced in the codebase; a CI gate with an explicit override annotation; explanatory output that teaches.
• Hard part. Being right often enough to stay installed. Parsing real migration syntax is fiddly, “dangerous” depends on engine and table size, and a linter with false positives gets disabled in a week and never re-enabled. Precision is the product.
• Stretches. Parsing and abstract syntax trees, database internals, static analysis, error-message craft, and designing an escape hatch that does not become the default.
• Smaller. One engine, one migration format, a fixed rule list, no codebase cross-referencing.
• Bigger. Estimate lock duration from table statistics and warn only above a threshold, with the estimate’s accuracy measured against real timings.

17. Repo Onboarding Doctor

• Problem / user. Every new contributor to a project loses a day to environment problems that the existing team solved so long ago they forgot they solved them.
• MVS — “Check, explain, fix” (5 slices, ≈42 h). A declarative check file living in the repository; a runner that verifies runtime versions, required variables, reachable services, and tool availability; actionable remediation text per failure; a machine-readable result; a check plugin interface.
• Hard part. Cross-platform truth. The same check behaves differently on three operating systems and two shells, and a check that is subtly wrong is worse than no check because it teaches people to ignore red. You will spend the schedule on the matrix, not the runner.
• Stretches. Cross-platform engineering, process invocation, plugin architecture, developer-experience writing, and testing a tool whose job is to inspect environments.
• Smaller. One operating system, a fixed built-in check list, no plugin interface.
• Bigger. Optional automated remediation behind an explicit flag, with a dry-run mode and a written safety argument for every action it will take.

18. Dependency Change Explainer

• Problem / user. A maintainer facing a lockfile diff with two hundred changed lines and no way to tell which of them can actually affect their code.
• MVS — “Diff, resolve, narrow” (5 slices, ≈45 h). Parse two lockfile versions; classify direct versus transitive changes; build the import graph of the project; report which changed packages are actually reachable from your code; a summary a human can read in ninety seconds.
• Hard part. Reachability. Dynamic imports, reflection, plugin loading, and conditional requires make “do we call this?” undecidable in general — so the project is really about being usefully conservative and saying plainly what you cannot determine.
• Stretches. Static analysis, graph construction, ecosystem-specific package resolution, and the discipline of designing honest output for an uncertain analysis.
• Smaller. One package ecosystem, direct dependencies only, no reachability analysis.
• Bigger. Ingest published advisory data from a source you have verified and rank changes by whether a reachable path touches a known issue.

19. Record-and-Replay HTTP Fixtures

• Problem / user. Any developer whose test suite calls a live third-party service and therefore fails on a plane, breaks when a vendor has a bad morning, and burns quota.
• MVS — “Record once, replay forever” (5 slices, ≈43 h). A recording proxy or client shim; a matching rule that decides which recording answers a request; replay mode with a clear failure when no recording matches; secret redaction at record time; a cassette-file format documented for humans.
• Hard part. The matcher. Which headers, query parameters, and body fields must match for a recording to be a valid answer? Too strict and nothing ever matches; too loose and your tests pass against the wrong response. There is no universal answer, so you must make the policy configurable and defend the default.
• Stretches. HTTP semantics, proxying, serialization format design, secret handling, and test-infrastructure ergonomics.
• Smaller. One HTTP client library, exact-match on method and URL only, manual redaction with a documented checklist.
• Bigger. Recording expiry with a scheduled re-record job that diffs the new response against the old and fails loudly when the vendor’s contract changed.

D.5 — Security

Two standing rules for this section. Test only systems you own or have written permission to test, and keep that permission in the repository. And do not invent cryptography — use a vetted implementation and make your contribution the thing around it.

20. Secret Scanner With a False-Positive Budget

• Problem / user. Every team that has ever committed a credential, which is every team. Existing scanners exist; most get muted because they cry wolf.
• MVS — “Scan history, rank, hook” (5 slices, ≈44 h). Walk repository history; detect known credential shapes and high-entropy strings; rank findings by confidence; emit machine-readable output; a pre-commit hook that blocks the obvious cases. Never transmit a candidate secret anywhere.
• Hard part. Precision, measured. You need a labeled corpus of true and false positives that you construct, and a reported precision and recall — otherwise “it found some stuff” is your whole result. Test fixtures, base64 blobs, and generated identifiers will drown you in noise.
• Stretches. Git internals, pattern design, entropy heuristics, evaluation of a detector, and building a corpus with an annotation guide.
• Smaller. Working-tree scan only, a fixed pattern list, no ranking — but keep the labeled evaluation set. That is the part that earns points.
• Bigger. History rewriting guidance and a rotation runbook, plus a measurement of how the hook changes commit behavior over four weeks.

21. Web Posture Reporter

• Problem / user. A small nonprofit, a club, or a department runs a handful of sites and has no idea whether their transport and header configuration is reasonable. They are told to “check security” and cannot.
• MVS — “Collect, interpret, prioritize” (5 slices, ≈42 h). For a list of hosts you own or have written permission to scan: collect response headers and certificate facts; evaluate against a rule set; produce a prioritized report with a plain-language explanation and a concrete fix; track changes across scans; rate-limit politely by default.
• Hard part. Interpretation, not collection. Grabbing headers takes an afternoon; deciding what actually matters for this site without cargo-culting advice from a blog post takes the semester. Every rule needs a written rationale and a condition under which it does not apply.
• Stretches. Transport layer security fundamentals, HTTP semantics, rule-engine design, technical writing for non-experts, and scanning ethics.
• Smaller. Header analysis only, one host, a fixed rule list, report to the terminal.
• Bigger. Scheduled scans with change alerts and a written remediation runbook the organization can execute without you — which is also your handoff artifact.

22. Least-Privilege Differ

• Problem / user. Anyone running cloud infrastructure who granted broad permissions during a deadline and has never taken any back. The permissions are still there.
• MVS — “Granted versus used” (5 slices, ≈46 h). Ingest policy definitions from an account you control; ingest access logs over a window; compute granted-minus-observed; propose a reduced policy; a confidence label on every recommendation.
• Hard part. Absence of evidence. A permission unused for thirty days may be a quarterly job, a disaster-recovery path, or genuinely dead — and removing the wrong one takes down a system at the worst possible moment. Your confidence model, and your refusal to over-claim, is the whole contribution.
• Stretches. Identity and access modeling, log analysis at volume, policy generation, risk communication, and designing a recommendation that is safe to act on.
• Smaller. One service, one identity, a report only — no generated policy.
• Bigger. A staged enforcement workflow: shadow mode, warn mode, enforce mode, with rollback and a written change-control procedure.

23. Threat Model as Code

• Problem / user. Small teams that skip threat modeling because it means a whiteboard session nobody schedules and a document nobody updates.
• MVS — “Describe, render, check” (5 slices, ≈44 h). A small declarative format for components, trust boundaries, and data flows; a rendered diagram; generated threat prompts per flow using a standard mnemonic taxonomy; a mitigation register; a gap report linking mitigations to actual tests in the repository.
• Hard part. Making the output specific enough to act on. Generated threats are generic by nature, and a list of forty vague risks gets ignored. The value lives in the mapping from an architecture element to a testable mitigation you can prove exists.
• Stretches. Domain-specific language design, diagram generation, security methodology, traceability, and integrating a document into a build.
• Smaller. Diagram plus threat prompts, no traceability to tests; the mitigation register is a hand-maintained table.
• Bigger. A CI gate that fails when a new data flow crosses a trust boundary without a linked mitigation — plus an escape hatch and the policy governing it.

D.6 — Systems and Networking

This domain earns respect and demos poorly. Budget presentation time in Week 15 for making invisible correctness visible — a fault-injection run projected live is worth more than any slide.

24. A Small, Durable Key-Value Store

• Problem / user. You, and every engineer who has taken durability on faith. The user is a learner and the artifact is a proof.
• MVS — “Log, index, recover” (5 slices, ≈47 h). An append-only write-ahead log; an in-memory index; crash recovery on startup; compaction; a simple line protocol and client; a fault-injection harness that kills the process mid-write and verifies invariants.
• Hard part. Proving durability rather than claiming it. Building the harness that reliably crashes you at the ugliest moment — mid-append, mid-fsync, mid-compaction — and a checker that detects torn records and lost acknowledged writes is more work than the store itself, and it is the reason the project is credible.
• Stretches. File system semantics and fsync, crash-consistency reasoning, binary format design, property-based testing, and benchmarking.
• Smaller. No compaction — an ever-growing log with a documented size limit and an honest note about the tradeoff.
• Bigger. Range queries via a sorted on-disk structure, with measured read amplification and a comparison against your original design.

25. An HTTP Server From Sockets

• Problem / user. Every developer who uses a web framework and could not say what happens between the socket and the handler. You are building understanding, and the artifact proves it.
• MVS — “Parse, serve, survive” (5 slices, ≈46 h). Request parsing from raw sockets; persistent connections; chunked transfer; static file serving with correct conditional responses; a conformance suite for the behaviors you claim; a load test with reported percentiles.
• Hard part. Framing under arbitrary segmentation. TCP will hand you half a header line, then three requests in one read, and your parser must be a state machine that survives every split. Add resource limits — slow clients, oversized headers, unbounded bodies — and you have the semester.
• Stretches. Socket programming, protocol state machines, concurrency models, resource limiting and denial-of-service resistance, and benchmarking methodology.
• Smaller. Single-connection-at-a-time, no chunked encoding, no keep-alive; conformance suite still required.
• Bigger. An event-loop concurrency model measured against the threaded one under identical load, written up with the conditions where each wins.

26. Home Network Visibility

• Problem / user. Anyone who wants to know what the twenty-three devices on their own home network are actually talking to, without shipping their traffic to a third party.
• MVS — “Capture, summarize, show” (5 slices, ≈45 h). Passive capture on a network you own; per-device bandwidth and destination summaries; a local-only dashboard; a retention policy that discards payload; an explicit written statement of what the tool refuses to record.
• Hard part. Keeping up without lying. Capture that silently drops packets produces confident, wrong numbers, so you must measure and report your own drop rate. Second hard part: privacy design, which for once is a design constraint rather than a chore.
• Stretches. Packet capture, protocol dissection, ring buffers and back-pressure, aggregation at rate, and privacy-by-design as an engineering discipline.
• Smaller. Flow summaries from your router’s own logs instead of live capture; same dashboard, a fraction of the risk.
• Bigger. Anomaly alerting on a new destination or a volume spike, with the false-positive rate measured over two weeks of real traffic.
• Standing rule: your own network only, with everyone in the household told. Anything else is not a capstone, it is a conduct case.

27. A Job Runner With Semantics You Can Prove

• Problem / user. Every application that eventually needs to do something slow later — send the email, resize the image, generate the report — and every developer who has sent that email twice.
• MVS — “Enqueue, retry, prove” (5 slices, ≈45 h). A durable queue; workers with visibility timeouts; retry with backoff; a dead-letter path; idempotency keys enforced at the handler boundary; a dashboard showing depth, age, and failures.
• Hard part. Proving the semantics under failure. At-least-once delivery is easy to claim and hard to demonstrate — you must build the harness that kills workers mid-job, partitions the store, and shows that no acknowledged job is lost and that a duplicate delivery does not double-charge.
• Stretches. Distributed-systems fundamentals, failure injection, idempotency design, observability, and writing a precise guarantee statement.
• Smaller. Single worker, in-process, durable to one local store; retries and dead-lettering still required.
• Bigger. Scheduled and delayed jobs with a documented clock-skew analysis, plus a fairness policy so one noisy tenant cannot starve the queue.

D.7 — Embedded and Hardware

Order your parts in Week 2 and buy two of everything. Shipping delays and a dead sensor in Week 11 have ended more hardware capstones than any bug.

28. Long-Run Environment Logger

• Problem / user. A greenhouse volunteer, a plant nursery, a home brewer, or an archive room custodian who wants to know what happened overnight and currently guesses.
• MVS — “Log locally, sync eventually” (5 slices, ≈46 h). Microcontroller reading temperature, humidity, and one more sensor; local buffered storage; sync to a small server when the network allows; a web view with history; configurable alert thresholds.
• Hard part. Weeks, not minutes. Wi-Fi drops, the clock drifts, the power blinks, the sensor drifts out of calibration, and the flash fills. A logger that works for an afternoon is a demo; the project is the one that survives a documented thirty-day run with a gap report.
• Stretches. Embedded C or MicroPython, sensor calibration, buffering under constrained memory, time synchronization, and long-run reliability testing.
• Smaller. One sensor, wired power, wired network, seven-day run.
• Bigger. Battery power with a measured power budget, or a mesh of three nodes with a documented conflict-free time base.

29. Counter With a Ground Truth

• Problem / user. A library, a food pantry, a trailhead, or a campus gym that needs door or path counts to justify hours and staffing and currently estimates.
• MVS — “Count, validate, report” (5 slices, ≈41 h). A break-beam or motion sensor and microcontroller; debounced counting with direction if your sensor supports it; local storage plus periodic upload; a daily and hourly report; a written validation protocol comparing device counts against hand counts.
• Hard part. Truth. Two people walking abreast, a person who pauses in the beam, a cart, a swinging door — every one of these is a counting error, and the project’s value is the measured error rate, not the count. Your validation protocol is the deliverable.
• Stretches. Sensor interfacing, debouncing and hysteresis, measurement methodology, error quantification, and enclosure and mounting realities.
• Smaller. Unidirectional counting, single site, a two-day validation window.
• Bigger. Two-sensor directional counting with occupancy estimation, and a reported confidence interval on occupancy at any hour.

30. Assistive Switch Interface

• Problem / user. A person with limited fine motor control, and the caregiver or occupational therapist who needs a device’s controls mapped to large accessible switches, foot pedals, or a sip-and-puff input.
• MVS — “Map, configure, persist” (5 slices, ≈47 h). A microcontroller presenting as a standard USB input device; three to five switch inputs; configurable mappings to key, mouse, or media actions; dwell and hold timing options; a configuration tool a non-programmer can operate, with settings stored on the device.
• Hard part. Two hard parts that must both land: getting the device descriptor and timing right so it works on an unmodified computer with no drivers, and a configuration experience a caregiver can use without you in the room. The second one is what makes it a capstone rather than a firmware exercise.
• Stretches. USB device classes, firmware timing, persistent configuration, accessibility-centered design, and testing with an actual user.
• Smaller. Two fixed inputs, mappings compiled in, no configuration tool.
• Bigger. Scanning input mode for a single-switch user, with timing options tuned in a session with a real user and the findings written up.

31. Cold-Chain Compliance Logger

• Problem / user. A food pantry, a community fridge, or a small clinic that must show a temperature record for a monthly report and currently writes numbers on a clipboard when someone remembers.
• MVS — “Sleep, sample, prove” (5 slices, ≈44 h). Battery-powered logger with a temperature probe and local storage; a configurable sample interval; an audible or visual excursion alarm; a monthly report export; a documented power budget with measured current draw.
• Hard part. The power budget. Running for weeks on a battery forces genuine sleep-mode engineering, measured current in each state, and arithmetic you must actually validate with a meter rather than a datasheet. Every naive firmware drains the cell in four days.
• Stretches. Low-power design, measurement instrumentation, real-time clocks, data integrity across power loss, and writing a report for an auditor rather than an engineer.
• Smaller. Wall power, no alarm, a fixed sample interval, export by removing the storage card.
• Bigger. Tamper-evident records — a hash chain over readings — with a written argument for exactly what that does and does not prove.

D.8 — Games and Simulation

The scope killer here is content, not code. Fix your art and level budget in Week 2 and treat it as a hard constraint, because “one more level” is infinitely available.

32. A Deterministic Roguelike

• Problem / user. Players who want a game whose runs can be shared, compared, and argued about — and you, who need a project whose test oracle is built into the design.
• MVS — “Seed, run, replay” (5 slices, ≈45 h). Seeded procedural generation; a turn loop; twenty to thirty items and effects; save and load; a replay file that reproduces a full run exactly from the seed and the input sequence.
• Hard part. Determinism. Iteration order over a hash-based collection, floating-point differences, and any stray call to a global random source will break replay, and the bug appears three hundred turns in. Chasing determinism is the schedule — and the payoff is that every replay becomes a regression test.
• Stretches. Procedural generation, random-number discipline, deterministic simulation, serialization, and building a test suite from real play sessions.
• Smaller. One dungeon type, ten items, no save/load — replay from seed plus inputs covers persistence.
• Bigger. A headless mode plus a scripted bot that plays a thousand seeds nightly and reports crashes, unwinnable layouts, and balance statistics.

33. Signalized Intersection Simulator

• Problem / user. A traffic engineer or a city committee arguing about whether a light’s timing is the cause of the afternoon backup, with nothing but opinions and a video.
• MVS — “Model, calibrate, compare” (5 slices, ≈46 h). A discrete-event model of one intersection; vehicle arrivals from counts you collect yourself; fixed-time versus actuated signal logic; delay and queue-length distributions across replications; a comparison report with intervals.
• Hard part. Validation. A simulation nobody can check is a screensaver with a legend. You must calibrate arrivals against real counts, compare simulated delay against observed delay, and report where the model disagrees with reality instead of hiding it.
• Stretches. Discrete-event simulation, input distribution modeling, replication and confidence intervals, calibration, and communicating uncertainty to a non-technical audience.
• Smaller. One approach direction, fixed-time signals only, arrivals from a single distribution, no calibration beyond total volume.
• Bigger. A small corridor of two coordinated intersections, with an offset-optimization search and an honest account of the search’s limits.

34. Board Game Engine and Opponent

• Problem / user. Players of a mid-complexity abstract game with no decent digital opponent — including your own club, which is a real user you can actually interview.
• MVS — “Rules, bot, ladder” (5 slices, ≈47 h). A complete legal-move generator; a rules test suite including the ugly edge cases; a playable interface; one search-based opponent; a round-robin harness that measures strength between versions.
• Hard part. Rules correctness. Every real ruleset has a handful of interactions that break naive implementations — forced captures, repetition rules, simultaneous resolution — and a bot built on a wrong generator produces confidently illegal brilliance. Perft-style exhaustive move counting at increasing depth is how you prove it.
• Stretches. Game-tree search, evaluation function design, exhaustive testing strategies, performance profiling, and experiment design for measuring strength.
• Smaller. A smaller board or a reduced variant, a fixed-depth search with a simple evaluation, and strength measured against a random player.
• Bigger. Tree search with learned evaluation, plus a reproducible ladder showing the improvement with error bars rather than a single win rate.
• Before you commit: implement a public-domain ruleset or your own. Do not ship somebody’s artwork, board design, or trademarked name.

35. Netcode Prediction Sandbox

• Problem / user. Every developer who has read three blog posts about client-side prediction and still cannot make a character stop rubber-banding — a teaching artifact with a real and grateful audience.
• MVS — “Predict, reconcile, visualize” (5 slices, ≈46 h). An authoritative server with a fixed tick; two clients; client-side prediction; server reconciliation; an artificial latency, jitter, and loss knob; a visualization overlaying predicted, corrected, and authoritative positions.
• Hard part. Reconciliation correctness. Replaying buffered inputs after a correction, without drift and without visible snapping, is subtle, and the bugs only show up at latencies you must be able to induce on demand. The latency harness is a prerequisite, not a nicety.
• Stretches. Real-time networking, fixed-timestep simulation, interpolation and extrapolation, deterministic replay, and debugging visualization.
• Smaller. One client, movement only, no interpolation of remote entities.
• Bigger. Lag compensation for hit detection, with a written analysis of the fairness tradeoff it imposes on the player being shot at.

D.9 — Accessibility

Accessibility work is done with people, not for them. If your plan has no real assistive-technology users in it by Week 3, you have a guessing project. The W3C’s Web Accessibility Initiative — https://www.w3.org/WAI/ — is the reference; cite the guidance by name, not by a version number you half-remember.

36. Accessibility Regression Gate

• Problem / user. A team that fixed their accessibility issues once, eighteen months ago, and has been quietly re-breaking them with every release since.
• MVS — “Automate, script, track” (5 slices, ≈43 h). Automated checks running in CI over key pages; a written manual test script covering keyboard-only operation and one screen reader; an issue register with severity and owner; a trend report across releases; a gate that fails on new violations only.
• Hard part. Automated tools catch a minority of what actually blocks people. The project’s real content is the manual protocol, the triage rules that decide what “severity” means, and the sessions with actual users — none of which a tool produces for you.
• Stretches. Assistive technology fundamentals, test protocol design, CI integration, triage and prioritization, and writing findings developers will act on.
• Smaller. Five key pages, automated checks plus a keyboard-only manual script, a report instead of a gate.
• Bigger. Moderated sessions with three assistive-technology users, with findings, a prioritized remediation plan, and a measured before-and-after on one task.

37. Plain-Language Assistant With a Human Gate

• Problem / user. A clinic, a housing office, or a legal-aid group whose public documents are written at a reading level their clients cannot use, and whose staff have no time to rewrite them.
• MVS — “Measure, suggest, approve” (5 slices, ≈45 h). Import a document; compute readability and structural metrics; produce suggested plain-language rewrites section by section; a side-by-side review interface where a human approves, edits, or rejects each; an export that preserves structure and an audit trail.
• Hard part. Meaning drift. Simplification that changes what a benefits notice legally says is a harm, not a feature, so you need a reviewer protocol, a diff that surfaces removed conditions and qualifiers, and an evaluation on documents where a domain expert judged the output.
• Stretches. Text processing, readability measurement and its limits, human-in-the-loop workflow design, evaluation with expert raters, and writing about risk honestly.
• Smaller. Measurement and flagging only — highlight long sentences, jargon, and passive constructions, and suggest nothing. Useful, safe, fully evaluable.
• Bigger. A domain glossary the organization maintains, plus a measured comparison of comprehension on the original and revised text with real readers.

38. Caption and Transcript Workshop

• Problem / user. A small media team, a campus ministry, or a lecture series that publishes video with no captions because correcting a machine transcript takes longer than the video.
• MVS — “Draft, correct, export” (5 slices, ≈46 h). Upload audio; produce a draft transcript with a speech model of your choosing; a correction editor with word-level audio synchronization and full keyboard operation; speaker labeling; export in a standard caption format; a quality step measuring word error rate against a reference you transcribe by hand.
• Hard part. The editing experience. Draft accuracy is never enough, so the project succeeds or fails on how fast a human can fix it — click a word, hear that word, retype, keep timing intact. Measure correction throughput in words per minute before and after your changes; that number is your result.
• Stretches. Audio synchronization, editor interface design, keyboard accessibility, caption format standards, and measuring a human workflow.
• Smaller. Single speaker, no speaker labeling, one export format, transcript-only with paragraph timing.
• Bigger. Terminology adaptation for a recurring domain vocabulary, with a measured reduction in word error rate on names and jargon.

39. A Data Table Anyone Can Actually Use

• Problem / user. Non-visual users of any application with a complex table — sortable, filterable, with grouped headers and summary rows — which is nearly every administrative tool, and nearly all of them are unusable without sight.
• MVS — “Pattern, prove, publish” (5 slices, ≈42 h). One thoroughly implemented table component with sorting, filtering, pagination, and summaries; announced state changes; complete keyboard operation; a documented test protocol; a published pattern write-up with the reasoning behind every decision.
• Hard part. This is a research project wearing a component’s clothes. Recruiting testers, running sessions well, and turning contradictory feedback into a defensible pattern is the work — and no amount of code substitutes for it. Start recruiting in Week 3.
• Stretches. Assistive technology behavior, accessible interaction patterns, user research methodology, technical writing, and library packaging and documentation.
• Smaller. Sorting and keyboard navigation only, tested with two users, published as documented example code rather than a package.
• Bigger. A comparison of two interaction patterns for the same task, tested with five users, reported with task times and errors and an honest statement of what a sample that size can support.

D.10 — Civic and Nonprofit Software

The best-fit domain in this catalog for what this course grades: a real client, a real deadline, a real handoff. It also has the highest client risk. Get the scope in writing in Week 2 and name a backup plan for the week your contact goes quiet.

40. Pantry Intake and Inventory

• Problem / user. A volunteer-run food pantry tracking who was served and what is on the shelves using two clipboards and a memory, and owing a monthly count to a partner agency.
• MVS — “Intake, stock, report” (5 slices, ≈45 h). Minimal-PII household intake; inventory by category with in and out movements; a distribution record; the monthly report the pantry actually has to file; a volunteer-mode interface that works with intermittent connectivity in a basement.
• Hard part. Two constraints pulling opposite directions: data minimization — collect the least that satisfies the report, and be able to say exactly what you store, why, and for how long — and an interface a rotating cast of volunteers can use correctly on their first shift with no training.
• Stretches. Privacy-by-design, offline tolerance, report generation to an external specification, interface design for infrequent users, and a handoff package for non-technical maintainers.
• Smaller. Anonymous household counts instead of records, inventory by category only, a single monthly report.
• Bigger. Multi-site inventory with transfers between locations and a written data-retention and deletion policy the board formally adopts.

41. Congregation Care Coordinator

• Problem / user. Deacons or a care committee coordinating meals, rides, and visits by group text. Two families bring lasagna on Tuesday and nobody comes Thursday.
• MVS — “Need, slot, confirm” (5 slices, ≈41 h). Create a need with date range and notes; sign up for a slot; dietary and access constraints; a coordinator view of coverage gaps; a printable weekly sheet for people who will not use a website.
• Hard part. Designing for someone who will use this once every four months. There is no learning curve to climb — the interface has to be legible cold, on a phone, by a seventy-year-old in a hurry — and slot conflicts must be impossible rather than merely discouraged.
• Stretches. Interaction design for infrequent users, conflict-free reservation logic, privacy in a small community, print output, and handoff to a volunteer administrator.
• Smaller. Meals only, one need at a time, coordinator-entered signups, printed sheet as the primary output.
• Bigger. Recurring needs and reminders through a channel of your choosing, plus a documented rotation policy so the same four families are not carrying it all.

42. Public Meeting Minutes Search

• Problem / user. Residents and local reporters trying to find when the council discussed a zoning change, faced with a decade of PDFs organized by date and nothing else.
• MVS — “Fetch, extract, find” (5 slices, ≈44 h). Polite scheduled fetching of published documents; text extraction; a search index with date and body filters; a results page linking to the authoritative source document; an extraction-quality report.
• Hard part. PDFs. Scanned pages, two-column layouts, tables, and optical character recognition errors will fill your schedule, and you must never present an extracted snippet as authoritative — every result links to the original, and your quality report says plainly what fraction of pages extracted cleanly.
• Stretches. Document processing, text extraction and its failure modes, search relevance and evaluation, ethical and polite fetching, and honest presentation of uncertain data.
• Smaller. One body, one year, manually downloaded documents, keyword search with no relevance ranking.
• Bigger. Entity and topic extraction so a resident can follow one parcel or one project across years — with precision and recall measured on a hand-labeled sample.
• Before you commit: confirm the documents are published, that fetching them is permitted, and that you can extract usable text from a sample of ten before this becomes a candidate.

43. Volunteer Hours Ledger

• Problem / user. A nonprofit that must report volunteer hours to a grantor and currently reconstructs them from paper sign-in sheets and guesswork at the end of the quarter.
• MVS — “Check in, correct, export” (5 slices, ≈40 h). A kiosk check-in and check-out; a correction workflow for the volunteer who forgot to check out; an activity category per shift; a supervisor approval step; an export matching the grantor’s required format exactly.
• Hard part. Human error and auditability. People forget to check out, check in twice, or leave without touching anything, so the system must make corrections easy and leave an audit trail an auditor accepts — original value, corrected value, who changed it, when, and why.
• Stretches. Audit-trail design, workflow and approval modeling, export to an external specification, kiosk-mode interface constraints, and documentation for auditors.
• Smaller. Supervisor-entered hours instead of a kiosk, one activity category, a monthly export.
• Bigger. Self-service check-in from a personal device with location or code verification, plus a written analysis of the fraud model it does and does not address.

D.11 — Education Technology

One rule: partner with a real instructor and a real course, or pick a different domain. Educational software without a classroom is a set of screens, and measuring learning is a discipline you will have to respect.

44. Retrieval Practice for One Real Course

• Problem / user. Students in a specific course — organic chemistry, anatomy, a language, a licensure prep — for whom no good practice material exists because the content is local to one instructor.
• MVS — “Author, schedule, analyze” (5 slices, ≈43 h). An instructor authoring interface with item review; a spacing scheduler; a student practice session; per-item difficulty analytics for the instructor; an export so the content outlives your project.
• Hard part. Item quality and evidence, not the algorithm — the scheduler is a well-solved problem you should implement plainly and move past. Showing that anything was learned requires an assessment design, a comparison condition, and a modest, careful claim.
• Stretches. Learning-science literacy, assessment design, analytics, instructor-facing tooling, and making a defensible claim from a small sample.
• Smaller. One unit of one course, instructor-authored items only, a fixed spacing schedule, engagement reported instead of learning gain.
• Bigger. A within-subject comparison across two units with pre- and post-tests, written up with the limitations stated before the results.
• Note: Chapter 2 rejects a generic study-tool idea for failing the evidence gate. This entry passes only if you have a specific instructor, a specific course, and a specific reason existing tools do not serve it. Without those three, it is the same rejected idea in a new shirt.

45. Autograder for One Course

• Problem / user. An instructor and a teaching assistant hand-running student submissions, and students who wait nine days for feedback on code they wrote in an evening.
• MVS — “Submit, sandbox, explain” (5 slices, ≈48 h). Submission intake; sandboxed execution with time, memory, and network limits; test-based scoring; feedback rendering that teaches rather than just failing; an instructor override and regrade path.
• Hard part. The sandbox. Student code is untrusted code, and every naive approach — a subprocess with a timeout, a temp directory, a permissions tweak — is escapable. Choosing an isolation mechanism, arguing for it in writing, and testing it against deliberate abuse is the project’s spine.
• Stretches. Isolation and containment, resource limiting, queueing under burst load, security threat modeling, and fairness and appeals as design requirements.
• Smaller. One language, instructor-triggered batch runs instead of on-demand submission, a documented and accepted isolation limitation.
• Bigger. Partial credit from structured test metadata plus plagiarism-signal reporting — with an explicit written policy that a signal is never an accusation.

46. Calibrated Peer Review

• Problem / user. An instructor who assigns peer review and gets back a mix of thoughtful critique and one-word compliments, with no way to tell which is which.
• MVS — “Assign, review, calibrate” (5 slices, ≈44 h). Reviewer assignment that handles drops and conflicts of interest; rubric-driven review forms; calibration items scored by the instructor in advance; a reviewer-reliability report; an instructor dashboard.
• Hard part. Measuring reviewers. Inter-rater agreement is a real statistical topic with real pitfalls, especially with sparse overlap between reviewers, and the assignment algorithm must guarantee coverage while surviving late drops without a manual rescue every week.
• Stretches. Matching and assignment algorithms, agreement statistics, rubric design, dashboard design for a non-statistician, and testing a system whose input is human judgment.
• Smaller. Random assignment with manual conflict handling, a fixed rubric, agreement reported on calibration items only.
• Bigger. Weight peer scores by demonstrated reliability, with the weighting scheme published to students in advance and defended in writing.

47. Misconception Diagnostic

• Problem / user. An instructor who knows students leave a unit with predictable wrong mental models but cannot tell which students hold which one until the exam.
• MVS — “Author, diagnose, report” (5 slices, ≈42 h). Item authoring where every distractor is tagged to a named misconception; a short diagnostic students take; a per-student and per-class misconception profile; an instructor report suggesting where to reteach; item-analysis statistics.
• Hard part. Item validity. A distractor only diagnoses a misconception if students who hold it actually pick it, and that is an empirical claim you must test with item analysis — discrimination, distractor pull, and a review round with the instructor. This is psychometrics, and the code is the easy half.
• Stretches. Assessment theory, item analysis, working with a domain expert, statistical reporting, and interface design for an instructor with fifteen minutes.
• Smaller. One unit, eight items, class-level reporting only, item analysis on a single administration.
• Bigger. Adaptive item selection that narrows to a likely misconception in fewer questions, with the selection rule stated and its accuracy measured against the full instrument.

D.12 — Research Replication

The most honest capstone shape in this catalog, and the one students underrate. A well-run replication with a negative result is a real contribution and an excellent Week-16 presentation. Confirm data availability and license before Week 3 — that single check kills half of these ideas, and it should.

48. Reimplement a Paper’s Method and Benchmark

• Problem / user. Anyone who wants to use a published method and has only the paper. The user is the next reader — and, in a lab context, your advisor.
• MVS — “From the text, then the code” (5 slices, ≈46 h). Select one paper with a clearly specified method; reimplement from the text alone; build the evaluation harness; run the reported benchmark; a report of where you matched, where you did not, and what you had to guess; the guesses catalogued as a list.
• Hard part. The unstated. Preprocessing, initialization, hyperparameters, stopping rules, and tie-breaking are usually absent from the text, and each one is a fork in the road you must document. The second hard part is temperamental: reporting a mismatch as a mismatch rather than tuning until the number agrees.
• Stretches. Careful reading, experimental methodology, reproducible pipelines, sensitivity analysis, and scientific writing.
• Smaller. One of the paper’s several experiments, on the smallest dataset it uses, with a single seed and a stated limitation.
• Bigger. A sensitivity analysis over the parameters you had to guess, showing which guesses actually mattered — often more useful than the replication itself.
• Before you commit: confirm the data exists, that you may use it, and that you can obtain it — this week, with a real download and a dated note on the license. Do not assume anything is available.

49. Reproducibility Audit

• Problem / user. Every reader who has cloned a repository from a paper and failed to run it. The audience is a research community, and the deliverable is evidence.
• MVS — “Preregister, time-box, score” (5 slices, ≈43 h). A protocol fixed and committed before you start; a sample of papers from one venue or area claiming released code; a fixed time box per attempt; a clean-machine run of each; a structured scorecard with evidence for every judgment; an aggregate report.
• Hard part. Method and fairness. Your protocol must be decided in advance and followed even when it is inconvenient, your time box enforced honestly, and every failure documented with enough detail that an author could reproduce your failure. Getting this wrong makes the project not merely weak but unfair to real people.
• Stretches. Research methodology, preregistration discipline, environment isolation, systematic documentation, and writing about others’ work with precision and charity.
• Smaller. Eight repositories instead of thirty, one language ecosystem, a simple three-state outcome.
• Bigger. Contribute a documented fix upstream where a project was one small change from running, and report acceptance outcomes.
• Note: this project is unusually well aligned with this course — the clean-machine test you will run on your own repository in Weeks 13 and 16 is the same instrument. See Appendix C.

50. Reimplement and Measure a Classic System Component

• Problem / user. You, and anyone who has read about memory allocators, schedulers, compaction strategies, or compression codecs and never watched one behave under load.
• MVS — “Build, bench, compare” (5 slices, ≈47 h). Implement one component against a documented reference design; a correctness test suite; a benchmark harness with warm-up, repetition, and percentile reporting; a comparison against a well-established implementation on workloads you justify; a written analysis of where yours wins and loses.
• Hard part. Benchmarking that is not lying. Cold caches, an unpinned process, a noisy machine, an unrepresentative workload, and a mean reported instead of a distribution will each hand you a result that is confidently wrong. Methodology — and reporting variance — is the whole contribution.
• Stretches. Systems programming, performance measurement, statistical reporting, workload design, and the intellectual honesty to publish a benchmark where you lose.
• Smaller. One workload, one comparison implementation, correctness plus throughput only.
• Bigger. A workload generator with several documented profiles and a crossover analysis showing exactly where the tradeoff flips.

D.13 — Now Go Do the Week 2 Work

You have read fifty ideas. None of them is your capstone yet, and reading more of them will not make one become yours. That transition happens somewhere else, and Chapter 2 is where it happens.

Here is the honest accounting. Browsing project ideas feels like progress — it is pleasant, it is infinite, and it produces nothing you can commit. Chapter 2 budgets two and a half hours for generating candidates and two and a half hours for writing the memo. If your ratio is inverted, you are not deciding; you are shopping. Close the catalog.

What actually moves you forward, in order:

1. Take at most three seeds from three different sections of this appendix, and rewrite each one in the six-line problem frame from Chapter 2 — with a real number on the which costs line. If you cannot find that number, that candidate is not real yet.
2. Find the human being. Fifteen minutes of past-tense questions and three verbatim quotes. This is the field no catalog can fill for you, and it is weighted highest on the scorecard for exactly that reason.
3. Run the Get gate on every external dependency. One real call, one saved response, one dated note on the rate limit and the terms. Every “before you commit” line in this appendix exists because that gate is where good ideas quietly die.
4. Size it twice. Run the 240-Hour Scope Sizer on the Chapter 2 page, then estimate bottom-up by hand in vertical slices, and reconcile. My hour figures here are a third opinion from a stranger — treat them accordingly.
5. Kill two, in writing. Each rejection names the gate it failed. That paragraph is a letter to the exhausted version of you who exists in Week 10.
6. Write the memo at docs/scoping-decision.md, including the out-of-scope list of at least eight named items and a scope-cut trigger with a real date on it. Templates and worked good-and-bad examples are in Appendix B; the rubric that pays for all of it is in Appendix C; the workbench you will do it in is Appendix A; and any term here you do not recognize is in Appendix E.

One last thing, and it is the reason this appendix opens with the verse it does. Look back at the fifty and notice how small they are. A shift board for one dining hall. A counter with a validated error rate. A logger that survives thirty days. A table a blind user can actually operate. Not one of them will impress a stranger in a sentence, and every one of them is a genuine capstone — because what this course grades is not the size of the idea but whether you carried one system through a full life cycle and handed it to somebody else, working.

“For which of you, desiring to build a tower, does not first sit down and count the cost, whether he has enough to complete it?” (Luke 14:28, ESV). The counting is the discipline. And there is a companion to it worth naming here, because the temptation of a catalog is to look for the entry that will make you look good: “Let each of you look not only to his own interests, but also to the interests of others” (Philippians 2:4, ESV). The best filter in this whole appendix is not which idea is most impressive. It is which one puts something useful in a neighbor’s hands by December.

Then commit it and get to work — “Commit your work to the LORD, and your plans will be established” (Proverbs 16:3, ESV).

Pick three. Kill two. Build the one that is left.

See you on Monday.