Skip to main content

Problem Selection: Right-Sized, Motivated, Defensible

What This Concept Is​

A capstone problem is the one real problem your project will solve. Not a category, not a buzzword, not a stack -- a specific problem, owned by a specific kind of user, with a specific moment where that user notices your system is better than the status quo. Problem selection is the decision that makes every other capstone decision possible: which characteristics drive the architecture, which subdomains deserve hand-coded attention, which ADRs must be written, what the defense answers in week 6.

A defensible capstone problem has three properties at once:

  • Right-sized. The end-to-end happy path can be built, deployed, tested, and documented by one person in about 5 weeks, leaving week 6 for hardening and defense. If the problem is so large that a vertical slice takes 3 weeks, it is the wrong problem. If the problem is so small that week 2 has nothing to build, it is also wrong.
  • Motivated. You can say, in one sentence, who feels the pain and why the current solution is inadequate. "I think it would be cool to build X" is not a motivation. "Engineers on small teams waste 20 minutes every standup reconciling three different status sources" is.
  • Defensible. A grader or reviewer can probe your choice -- "why not just use Google Forms?", "why does this need a distributed system?" -- and you have an honest answer other than "because I wanted to learn it." The defense does not require you to be right in the abstract; it requires you to be right for this user, this problem, this budget.

The problem statement is the first line of the design doc. Every later section -- characteristics, style, ADRs, diagrams, risks, schedule -- is answerable only because the problem statement exists.

Why It Matters Here (In the Capstone)​

Most capstones fail in week 1, not week 5. They fail because the problem was wrong, and week 5 is just where the consequences surface. A problem that is too big forces scope-cuts that destroy the system's identity. A problem that is unmotivated cannot be defended. A problem that is not defensible cannot be graded well even if the code is good.

You have spent nine semesters learning to make engineering decisions. This is the decision that makes all the others possible. It is also the decision where the capstone most closely resembles the real world: staff engineers spend most of their scoping work fighting the same three failure modes -- problems that are too big, too theme-based, or too stack-driven.

Finally, this concept sets the lens through which the rest of Module 1 reads. The Top-3 Characteristics (concept 07) can only be ranked if you know the user and the pain. The MVP (concept 03) can only be defined as a vertical slice through a real problem. The ADRs (concept 12) only defend themselves against a real decision context. Skip this concept or blur it, and every downstream artifact sags.

Concrete Example(s) -- from a real capstone​

Bad problem (too large): "Build a Slack competitor with threads, reactions, search, and DM." Nothing in that sentence can be finished solo in six weeks.

Bad problem (unmotivated): "Build a URL shortener because I want to use Redis." The stack drives the problem; the user is absent.

Bad problem (indefensible): "Build a distributed event-sourced CQRS system for grocery lists." The grading probe -- "why?" -- has no honest answer.

Good problem A -- inventory service for a small warehouse. "Build an inventory-tracking service for a single-warehouse e-commerce shop with 2-4 staff. Staff scan barcodes during receiving and picking; the system reconciles on-hand vs promised vs shipped. The pain: the shop currently uses a spreadsheet, and miscounts during picking cause 1-2 oversells per week. My capstone provides a mobile-first scan-and-adjust flow, persists an audit log of every quantity change, and exposes a daily reconciliation view. It must keep working when Wi-Fi drops (staff keep scanning offline, sync when back)." Named user (warehouse staff), visible pain (oversells), success moment (audit log + daily reconciliation), implicit drivers (operability on flaky networks, offline-first, correctness of quantity counts).

Good problem B -- ticketing platform for a student club. "Build an event-ticketing platform for student-run clubs hosting 100-800-seat events. Organizers create events, set seat/tier limits, and issue QR tickets; door staff scan on arrival. Today the club uses a generic form tool that allows double-bookings and has no door-scan path. My capstone enforces per-tier caps atomically, serves QR tickets by email, and provides a door-scan mode that works on a phone in low-signal venues. Success condition: a 200-person event runs end-to-end on a Saturday night." Named users (organizer, door staff), pain (double-bookings, no scan), success moment (a live event runs), drivers (consistency of seat caps, offline-capable scanner, time-to-door).

Good problem C -- personal finance aggregator. "Build a read-only personal-finance aggregator for a single household -- 2 adults, 4-6 accounts, 2 credit cards. Today they export CSVs monthly and reconcile in a spreadsheet. My capstone pulls CSVs on a schedule (or on manual upload -- no bank API), categorizes, dedupes, and shows a month-over-month cash-flow view. Success condition: a single cashflow.md report for last month that matches hand-reconciliation to the cent." Named user (one household), pain (manual reconciliation), success moment (a reproducible monthly report), drivers (data correctness, idempotent import, privacy).

Across all three good problems: one or two named users, a visible ritual, a sharp pain, an observable success moment, and implicit architectural drivers the design doc can ground. These are the capstones that defend themselves.

Common Confusion / Misconceptions​

  • The Stack-First Trap. "I will pick the technologies first and find a problem to fit them." If the stack drives the problem, the grader will see it in your ADRs: the "context" section will be circular. Pick the problem. Then let the problem pick the characteristics, and only then the stack.
  • The Showcase Trap. Picking a problem because you have a library or framework you want to showcase. Frameworks are interchangeable. Problems are not. The showcase never survives scope-cutting -- the library becomes the thing you cut last and defend weakest.
  • The Inflation Trap. Inflating the problem to sound impressive. "A platform for real-time collaboration" sounds bigger than "a retro board for one team," but the bigger framing is harder to defend and harder to finish. Prefer the smaller, sharper framing; smallness is a feature, not an apology.
  • The Theme Trap. Confusing a theme ("I want to do healthcare", "I care about education") with a problem. A theme has no user and no success moment. If your "problem statement" could be the title of a category on an investor deck, you have a theme, not a problem.

Red Flags in a Problem Statement​

Scan your draft. If any of these are true, the statement is not yet defensible:

  • The user is "users" or "people" or "anyone who wants X." You have no user.
  • The alternative is "nothing currently exists." Something always exists; if you genuinely believe nothing does, you have not looked.
  • The differentiator is a technology ("because it uses GraphQL"). Technology is not a user-visible differentiator.
  • The success condition requires the grader to take your word for it ("the system feels fast"). Success must be observable without trust.
  • The problem could be entirely solved by a well-configured spreadsheet. That is a signal to go harder on why a system is needed at all.

A single red flag does not kill the problem; it is a prompt to rewrite the offending sentence.

How To Use It (In Your Capstone)​

Write a one-paragraph problem statement on day 1 using this template:

For [user type] who [painful situation], [capstone name] is a [category of thing] that [one-sentence benefit]. Unlike [alternative], our capstone [key differentiator]. The capstone will be considered working when [concrete observable success condition].

Then operationalize with this checklist:

  1. Name the user concretely. One role, one team size, one ritual. If you cannot name the user, stop.
  2. Describe the current painful workflow in one sentence. Include a frequency ("weekly", "per shift") so you can later estimate value.
  3. Name the alternative and one honest weakness. "Google Forms, but it cannot enforce per-tier seat caps."
  4. Write the success moment. An artifact, a 200-response, a row, a file -- something a grader can check alone.
  5. Circle the implicit drivers. Offline? Consistency? Time-to-deploy? These foreshadow Cluster 3.
  6. Cut every marketing verb. Strike "seamlessly", "leverage", "users", "empower". What remains is truth or empty.
  7. Commit to library/raw/problem.md. Week-5 you will try to re-theme the capstone under pressure; the committed paragraph pushes back.

See also (integrative)​

This concept integrates prior-semester work on framing and tradeoff reasoning. Use these when the problem draft feels mushy or the defense probe keeps winning.

External references (curation-validated this session):

Check Yourself​

  1. Who is the user of your capstone, stated in one sentence with a role and a team size?
  2. What is the single observable moment when the grader can tell it works -- without asking you any questions?
  3. Give one alternative to your capstone and one honest reason your capstone is better for this user.
  4. If the grader asked "could you cut this capstone to half its scope and still learn the thing?", what would you cut?
  5. What is the hard part of your problem that distinguishes it from a CRUD exercise? One sentence.
  6. Which of your top-3 characteristics (Cluster 3) is implied by your problem statement today? If none, the statement is not specific enough.

Mini Drill or Application (Capstone-scoped)​

  • Drill 1 (15 min). Write the one-paragraph problem statement using the template. Strike every phrase that is marketing or generic. If nothing remains, start over.
  • Drill 2 (15 min). Rewrite with a more specific user: a named role, a team size, a ritual. The paragraph should sharpen, not merely shorten.
  • Drill 3 (10 min). Write, below the paragraph, the five-line "why this?" memo: user, workflow, alternative, success moment, right-sized-ness.
  • Drill 4 (10 min). Show the paragraph to one peer (or read it out loud to yourself). Note every sentence that produces a "what do you mean by X?" question. Those are your rewrites for tomorrow.
  • Drill 5 (ongoing). Put the paragraph in library/raw/problem.md at the top of your repo. On every Friday of weeks 2-5, open it and strike one extra word that has become dead weight.

Source Backbone​

Capstone design applies earlier architecture and domain material. These books are the source backbone for the decisions in this module.