Chapter 2 — Reps

Twelve reps this week, in four blocks: Generate, Screen, Size, Decide. They are not warm-ups around the milestone — they are the milestone, built one piece at a time. Finish Rep 12 and the scoping decision memo is mostly written.

Ground rules

• Everything is about YOUR three candidates. No toy examples, no hypotheticals. If you do not have three yet, Rep 1 and Rep 2 are how you get them.
• A number or a quote, every time. A rep is not done until it produced something checkable by someone who is not you: a figure, a date, a status code, a sentence a human being actually said.
• Verify before you write it down. Anything an assistant tells you about an API, a library, a free tier, or a license goes through one real call or one vendor page — with the date — before it enters a document you sign.
• Log the hours as you go. Every rep, real minutes, into the hours log you built in Week 1. Rounding up to make yourself look diligent corrupts the only estimation data you will ever have about yourself.
• Commit as you finish. Each artifact lands in the repository the same day with a dated commit message. Uncommitted work does not exist.
• Write the reflections in prose. Two to four sentences. They are where the thinking actually happens.

Block 1 — Generate

Rep 1 — Ten problems, zero technologies

Write ten problems, one line each. Every technology noun is banned — no framework, no language, no database, no “app”, no “platform”, no “AI”. If you cannot describe the problem without naming a tool, you do not have a problem yet.

1. <who> loses <what> when <situation>, about <number> per <period>.
2. ...
10.

Reflect: Which three lines have a real number in them? Those are your candidates. Which lines did you have to delete a technology from — and what was left when you did?

Rep 2 — Mine four wells

Force breadth. Produce at least one candidate from each of four different wells in §2.2 — your work, your campus, your hobbies, open source, a real client, a research gap. Use Appendix D to prime exactly one of them, and mark that one as primed.

Reflect: Which well produced the candidate you find least exciting and most finishable? Sit with that for a minute. It is a real signal, and it is usually the client well.

Rep 3 — Three problem statements, in the frame

Take your three strongest candidates and write each one in the §2.1 frame — all six lines, including which costs with an actual number. Put each into its own copy of code/idea-canvas.md, saved as docs/ideas/candidate-a.md, -b.md, -c.md.

For              ____________________________________________
who              ____________________________________________
the problem is   ____________________________________________
which costs      ____________________________________________
Today they       ____________________________________________
which falls short because  ______________________________

Reflect: For which candidate was the which costs line hardest to fill? Say why in one sentence. A cost you cannot estimate is usually a problem you have not seen happen.

Block 2 — Screen

Rep 4 — Talk to one human being

Schedule and conduct one conversation with a person who has the problem. Five questions, all past tense, no pitch, no description of your idea until the very end. Model them on the good column of §2.6’s table.

1. Walk me through the last time <the problem> happened. What did you do?
2. What do you do about it today?
3. What is the most annoying part of how you handle it now?
4. Have you paid for or installed anything to deal with it?
5. When was the last time? And before that?

Write it up the same day: date, length, the workaround they named, and three verbatim quotes. Commit it as docs/interviews/<YYYY-MM-DD>-<initials>.md.

Reflect: What did they say that you did not expect? And — harder — at what moment did you catch yourself wanting to explain your idea instead of listening?

Rep 5 — Prove every dependency exists

For each external dependency in each candidate — an API, a dataset, a device, a permission, a data feed — make one real call or one real download, this week. Save the actual output. Record it:

curl -s -o /dev/null -w "%{http_code}\n" "https://<endpoint>"

If a dependency cannot be exercised this week, mark it UNVERIFIED in red letters in the canvas. An unverified dependency is not a dependency; it is a wish with a URL.

Reflect: Which dependency took longest to get working, and what does that predict about Week 9? Did any of them turn out not to exist, not to be free, or not to return what you assumed?

Rep 6 — The novelty-load audit

List every technology each candidate would require. Mark each one known (you have shipped something with it) or new (you have read about it). Count the new ones.

Novelty load above 2 is a warning. For any candidate above 2, write the sentence: “To keep this candidate I would swap ____ for ____, which I already know.”

Reflect: Be honest about one item you marked “known.” Have you actually shipped with it, or have you only followed a tutorial? The gap between those two is where estimates go to die.

Rep 7 — Estimate by hand, bottom-up

Take your leading candidate. For every Must feature, list the vertical-slice tasks and put hours on each: interface, handler, data access, validation, error path, test, documentation line.

Feature 1: ______________________
  interface ___ h   handler ___ h   data ___ h   validation ___ h
  error path ___ h  test ___ h      docs ___ h        subtotal ___ h
Feature 2: ...
                      feature total ___ h
  walking skeleton + CI ___ h    deployment + clean-machine test ___ h
                 CONSTRUCTION TOTAL ___ h    (plan 60, ceiling 75)

Reflect: Which feature surprised you by being expensive? Which task did you almost forget to include — and would you have remembered it in Week 10, or discovered it?

Block 3 — Size

Rep 8 — Run the Scope Sizer on all three

Use the 240-Hour Scope Sizer on this chapter’s page for every candidate, not just your favorite. Record the output, then apply the two cuts it names and re-run.

Then run the same model offline on all of them at once with code/size_check.py, using code/candidate-scorecard.csv as the format guide:

python3 size_check.py my-candidates.csv

Reflect: Which lever moved the number most — features, integrations, accounts, or novelty load? Was it the one you expected? Most students expect feature count and are wrong.

Rep 9 — Reconcile the two estimates

Put Rep 7’s hand estimate next to Rep 8’s model estimate for your leading candidate.

Bottom-up (Rep 7): ___ h        Sizer (Rep 8): ___ h
Gap: ___ %      The assumption that differs: _______________________
The number I will plan against: ___ h     because ___________________

If the gap is under about 30 percent, you have a defensible number. If it is more than a factor of two, one of the two is wrong and you find out which this week, not in Week 9.

Reflect: Which of the two do you want to believe, and which do you think is more likely correct? Notice that those are different questions. Estimators who cannot tell them apart ship late.

Rep 10 — The pre-mortem

Two versions, and do them in this order.

Yours first. Write, by hand, the three most likely ways this project fails. Then ask an assistant: “It is Week 16. This project failed and I am writing the post-mortem. Give me the three most likely causes, in order of probability, each with the earliest week it would have become visible.” Compare.

Log the prompt and what you kept in docs/ai-usage.md.

Reflect: Which failure did the model name that you did not? Which one did you name that it could not have known? That second one is the reason you are accountable and it is not.

Block 4 — Decide

Rep 11 — Kill two, in writing

Score all three candidates on the §2.5 scorecard. Then write two rejection paragraphs. Each one names the specific gate that failed, the number or the quote that killed it, and either the condition under which you would revisit it or the plain words closed, not deferred.

Reflect: Read your two rejections aloud. Does either sound like it was written to justify a decision you had already made? If so, rewrite it around the evidence instead of around the conclusion.

Rep 12 — The out-of-scope list

Write at least eight things you will not build, by name. Be specific: “email notifications”, not “extra features”. Include at least two you genuinely want to build.

Out of scope — will not be built:
1. ______________  5. ______________
2. ______________  6. ______________
3. ______________  7. ______________
4. ______________  8. ______________

Reflect: Which of the eight will be hardest to keep out at 11 p.m. in Week 10? Write one sentence to your future self explaining why it stays out. That sentence is the whole point of this rep.

Done? One Last Thing.

Assemble the memo, end to end. Everything above becomes one document:

1. Copy code/scoping-decision-memo.md into the repository as docs/scoping-decision.md.
2. Fill all ten sections from the reps: problem (Rep 3), evidence (Rep 4), chosen scope (Reps 7 and 9), Should features, out-of-scope (Rep 12), accepted tradeoffs, the two rejections (Rep 11), the reconciled hour budget, the one hard part, and the risks with a scope-cut trigger that names a real date (Rep 10).
3. Update the project board so every Must feature is a card, and update the hours log with this week’s real numbers.
4. Read it once as a stranger. Delete every sentence that cannot be checked. If a whole paragraph goes, good — it was decoration.
5. Commit: milestone-2: scoping decision, three candidates, two rejected.

If a classmate can read that document and tell you what you are building, what you are not, and what would make you cut scope — without asking you a single question — you are ready.

Up next: Milestone 2