Choose a real problem and narrow the scope

Why this matters

For seventy-seven days you followed instructions. Today that stops: you choose what to build, and nobody will tell you whether the idea is the right size. Most beginner capstones die here — not from missing skill, but from a scope that was never finishable. By the end of the hour you will have a one-page problem statement naming one user, one workflow, and the things you are deliberately not building, plus a reusable checklist for testing any future idea.

Nothing gets coded today. Today you decide what "done" will mean.

The problem comes before the app

An app idea is not a problem. "A platform for managing lab equipment" describes software. It does not tell you who is suffering, what they do instead right now, or how you would know the suffering stopped.

Start with three sentences you must be able to write before anything else.

• The user. One person, one role, singular. Not "labs" or "teams" — "Maya, the technician who owns the calibration schedule for eight bench instruments." If you cannot picture one specific person doing the work, you will build for nobody.
• What happens today without the app. The current process, honestly. "She keeps calibration dates in a spreadsheet and checks it when she remembers." If nothing happens today, the problem is probably imaginary.
• Why that hurts. The cost, concretely. "Twice last year an instrument was used past its calibration date and the measurements had to be repeated."

That third sentence is the load-bearing one. A problem with no cost has no user, and an app for a problem with no cost is an exercise you will abandon in week two.

The must-have workflow

A workflow is one loop the user runs repeatedly to get value. Your project needs exactly one to begin with, written as a single sentence in this shape:

<user> <does this> so that <this becomes true>.

For the calibration tracker: "Maya records that an instrument was calibrated so that she can see which instruments are overdue."

Two tests on that sentence, and both are strict.

The "and" test. If the sentence joins two different jobs with "and" — "records calibrations and orders replacement parts" — you have two projects. Delete one. You may add it back in a later week; you may not start with both.

The second-user test. If the workflow only delivers value once a second kind of user is also using the app, you have picked a multi-sided system. A messaging app is worthless with one user; a calibration log is useful to Maya alone on day one. Single-user-useful is what you want for a capstone.

Non-goals and constraints

A non-goal is something you are deliberately excluding from the current scope. Not something you forgot, not something impossible, not a bug — a real, sensible, desirable feature that you have decided is out of bounds for now, written down so that the decision survives contact with your own enthusiasm three days from now.

Unwritten non-goals do not exist. The feature creeps back in at 11pm as "it's only a small addition", and small additions are what eat capstones.

Write at least five. Good ones for the calibration tracker:

NON-GOALS (v1)
- No user accounts or login. Single trusted user on a local network.
- No email or SMS reminders.
- No file uploads for calibration certificates.
- No multi-lab or multi-tenant support.
- No mobile app. Responsive web only.

Constraints are the limits you did not choose. Write them next to the non-goals:

• Time. Two weeks of one-hour sessions, minus the days that go wrong.
• Skill. Exactly what days 1–77 taught. Nothing needing a technology you have never touched.
• Data. What you can legally and realistically store. Real names? Real measurements?
• Deployment. Where it will run, and whether that costs money.

The scoping checklist

Here is the reusable part. Run any project idea — this one, or one three years from now — through these six questions. Every answer must be yes.

1. Can you name one primary user in one sentence, as a person doing a job?
2. Can you say what that person does today instead, and what it costs them?
3. Is your core workflow one sentence with no "and" joining two jobs?
4. Is the workflow useful with only one user in the system?
5. Does the core workflow need three tables or fewer?
6. Have you written five or more non-goals?

Then the hard test, which catches everything the six miss:

A thin end-to-end slice is a feature that goes all the way from the database to the screen but does as little as possible on the way. It is thin, not short: it crosses every layer. You will build one on Day 82, and the whole point of today is making sure such a slice exists.

Walkthrough: narrowing one real idea

Watch a vague idea shrink until it passes the checklist.

Round 0 — the idea as first stated. "A platform for lab equipment management." Fails question 1 (no user), 3 (no workflow at all), 5 (no idea), 6 (nothing excluded).

Round 1 — find the person. Who feels this? "Maya, the technician responsible for eight bench instruments." Now question 1 passes. What does she do today? Spreadsheet, checked from memory. Cost: two repeated measurement runs last year. Question 2 passes.

Round 2 — find the loop. First attempt: "Maya manages instruments and books calibration appointments and stores certificates." Three jobs joined by "and" — question 3 fails. Which single job removes the cost? Not booking, not storage: knowing what is overdue. Rewrite: "Maya records that an instrument was calibrated so that she can see which instruments are overdue." One job. Question 3 passes, and question 4 passes because Maya alone gets value.

Round 3 — count the tables. Instruments, and calibrations belonging to instruments. Two. Question 5 passes. Vendors, certificates, and appointments all become non-goals — question 6.

Round 4 — the thin slice. "Record a calibration against an existing instrument and see it in that instrument's history." One table written, one endpoint, one form, one list — a demonstrable path, so the scope is real.

Your turn

Write docs/problem-statement.md in a new folder for your capstone. One page, no more.

1. Pick a domain you actually know. Lab inventory, calibration tracking, a project log, a service request queue — or your own. Familiarity beats novelty; you will be inventing the requirements, and you can only do that for work you understand.
2. Write the three sentences: the primary user, what they do today, what it costs them. Name the user like a person.
3. Write the core workflow in the <user> <does this> so that <this becomes true> shape. Apply the "and" test and the second-user test. Rewrite until both pass.
4. List five or more non-goals under a NON-GOALS (v1) heading. Include at least one feature you genuinely want, so the list costs you something.
5. List your constraints: time, skill, data, deployment.
6. Run the six-question checklist and write the answers down as six yes/no lines. Any "no" means go back to step 2 — this is the whole exercise, not a formality.
7. Write the thin slice as the last line of the page, in one sentence: one table, one endpoint, one screen.
8. Commit the file with a message like docs: problem statement for calibration tracker.

Common pitfalls

• Choosing a project to impress rather than to finish. A finished calibration tracker beats an abandoned social network in every conversation that matters.
• Writing non-goals that cost nothing. "No blockchain" is not a decision. Exclude something you actually wanted.
• Describing features instead of the workflow. A list of screens is not a workflow. The workflow is the loop the user repeats; screens exist to serve it.
• Confusing a non-goal with a constraint. A non-goal is a choice you made and can reverse later; a constraint is a limit imposed on you. Mixing them makes you reverse the wrong one under pressure.

Verify it yourself

Open today's reference, OpenAI's Codex CLI documentation, and find the guidance on how to phrase a task for the agent.

1. Look at what the docs say about giving context and scope in a request. Does the level of specificity they recommend look like your core-workflow sentence, or like your original vague idea? Write one line on the difference.
2. Find whether the docs suggest anything about the size of a task you hand the agent, and note whether your thin slice would fit.

Add both answers to the bottom of problem-statement.md. You are about to spend two weeks instructing an agent; how precisely you can state what you want is the whole game.