Chapter 2 — Finding an Idea Worth 240 Hours

“It always takes longer than you expect, even when you take into account Hofstadter’s Law.” — Douglas Hofstadter, Gödel, Escher, Bach (1979)

“Unless the LORD builds the house, those who build it labor in vain.” — Psalm 127:1 (ESV)

Why This Matters

Last week you built the machine: a repository, a board, an hours log, a charter, and a written decision about how you would use AI. You did all of that before you had an idea, on purpose. The engineering system is not a reward for having a good idea. It is the thing that tells you whether the idea is any good.

This week you wear the product owner’s hat. On a real team, the product owner decides what the software is for — who it serves, what it must do, and, more importantly, what it will never do. That person is not the smartest engineer in the room; they are the one who can say no and defend it. You are that person now, and you are also the engineer who has to live with the decision. Nobody is going to protect you from your own ambition.

You are still in inception — the first phase of the software development life cycle, and the shortest. It ends Sunday. By then you must have one project, three candidates’ worth of evidence for why it is the right one, and a written scoping decision that a stranger could read and agree with. Next week the analyst’s hat goes on and you start writing requirements. Requirements against an unscoped idea are a hallucination with headings.

Here is the arithmetic that governs everything in this chapter. The course budgets 240 hours. Only about a quarter of those hours — call it 60 — are hands-on-keyboard construction, and a third of those go to plumbing you cannot skip: the walking skeleton, continuous integration, deployment. Which leaves roughly 45 hours of net feature building for the entire semester. At seven to nine hours per honest vertical slice, that is five or six features. Not twenty. Five or six. Almost every capstone that dies, dies because its owner never did that division problem in Week 2.

The AI thread runs both ways this week. As a tool, an assistant is a genuinely useful sparring partner — it will expand a vague problem into a candidate feature list, name the ten tasks you forgot, and enumerate the ways an integration fails in production. It is also trained to be agreeable, which makes it a terrible judge of whether your project fits in your remaining hours. As a workload, this is the week you decide whether your project should contain an AI feature at all — and learn to tell an honest one, with an evaluation and a fallback and a cost cap, from a garnish bolted on so the title sounds current. The spine rule holds: the assistant argues, you decide, you sign your name.

And underneath all of it sits the week’s harder question, the one Psalm 127 asks in one line: how do you tell a worthy work from a vain one? Not a cheap question. You are about to spend a sixth of a year on something. Some things are worth that and some are not, and the difference is not measured in cleverness.

2.1 — Ideas Come From Problems, Not From Technologies

“The hardest single part of building a software system is deciding precisely what to build.” — Fred Brooks, “No Silver Bullet” (1986)

Brooks wrote that in 1986 and it has not aged a day. Notice what he did not say: that the hardest part is deciding what to build it with. Most capstone ideas arrive backwards. A student wants to use a technology — a framework from a job posting, a database they read about, an agent architecture that was on the front page last month — and then reverse-engineers a problem for it to solve. The result is always the same shape: an application nobody asked for, whose features exist to justify the stack, abandoned in Week 11 when the novelty wears off and the tedium arrives.

Turn it around. Start from a problem that costs a specific person something specific, and let the technology be an answer rather than a premise. Then when Week 11 arrives and the work is tedious — and it will be tedious — you will still have a reason to open the laptop, because somebody is still throwing out food. Here is what the difference looks like on paper.

Bad — technology-first: “I want to build a full-stack web app with React, an Express API, PostgreSQL, and a vector database for semantic search. Probably something with recipes.”

Bad — problem-shaped but empty: “Food waste is a huge problem worldwide. My app will help people reduce food waste using AI.”

Good:

Four students share a kitchen in an off-campus house. Nobody knows what is in the fridge or the pantry, so food gets bought twice and thrown out once. In March one of them counted roughly $40 of food discarded, mostly produce and dairy that expired unnoticed behind other things. Today they cope with a dry-erase board on the fridge, which nobody has updated since the second week of the lease, because updating it means standing in the kitchen with a marker while your arms are full of groceries. What is missing is a shared list that is faster to update than the whiteboard and that tells you what is about to go bad before you shop.

The third one is longer, and that is not an accident. It names a user, a situation, a cost with a number, an existing workaround, and the precise reason the workaround fails. Every one of those becomes a requirement in Chapter 3. The first two become nothing. Use this frame; it fits on an index card:

For              <a specific user, described concretely enough to find>
who              <the situation they are in when the pain happens>
the problem is   <what goes wrong, in their words>
which costs      <a number — dollars, minutes, errors, missed things, per what>
Today they       <the workaround that already exists>
which falls short because  <the specific reason the workaround fails>

If you cannot fill the which costs line with a number, you do not yet understand the problem. Go find the number. That is what §2.6 is for.

Coach’s Note — The technology question is not forbidden — it is just later. Week 5 is where you choose a stack and defend it in an architecture decision record. If your favorite technology genuinely is the right answer to the problem you found, it will still be there in three weeks, and this time you will be able to say why.

Meet the running example

This book will not tell you what to build. But it cannot show you a good requirements specification, a good decision record, or a good README without showing you some project’s, so from here to Week 16 the worked examples come from one place:

PantryPilot — a small web application that lets a household track what food it has, what is about to expire, and what can be cooked from it tonight. One student, one semester. Real users (a roommate group). A real data model. One third-party integration, a barcode/product-lookup API. An optional AI feature that suggests a recipe from what is on hand. And it has to run on somebody else’s machine.

PantryPilot is an example, not a template. Your project will be a different shape, and when it fits badly the second example is there for contrast:

TraceLens — a command-line tool that streams a server log file, flags anomalous patterns, and writes a report. No user interface. No accounts. No deployment target beyond “install it and run it.” Almost all of its difficulty is in the data.

Two shapes, one process. Whenever an example shows up, ask immediately: what is the equivalent thing in mine?

2.2 — Six Wells to Draw From

If you do not have a problem yet, you do not need inspiration — you need a systematic search. There are six places good capstone problems come from, and each has a characteristic strength and a characteristic way of wasting your semester.

Draw from at least three different wells; ideas from a single well share a single blind spot. And if you are staring at a blank page, Appendix D has fifty sized capstone ideas across a dozen domains, each with a scope estimate, the genuinely hard part, and one way to shrink it and one way to grow it. Use it to prime the pump — but do not adopt an entry wholesale. An idea you did not find yourself is an idea you will not defend in Week 16.

Coach’s Note — The client well is underrated and the hobby well is overrated. A campus office with a broken spreadsheet will give you a real user, a real deadline, real feedback, and a genuine handoff at the end — which is four of the things this course grades. Your fantasy football tool will give you none of them.

2.3 — The Feasibility Screen: Can You Build It, Get It, Ship It

An idea is not a candidate until it passes three gates. Most students run the first in their head, skip the second, and discover the third in Week 14. Run all three, in writing, this week, for all three candidates.

Novelty load is this book’s term for the number of technologies in a project you have never used before, and it is the single best predictor of a capstone overrunning. Everything you already know takes about as long as you think. Everything new takes two to three times as long, because the time goes to the errors you have not seen yet, and you cannot estimate an error you have not seen. Budget at most two genuinely new things. If your list has five, three of them have to become “known” on your own time before Week 9, or they get swapped out.

The Get gate is where good projects die quietly. “I will use the university’s course catalog API” is not a dependency. It is a wish, until somebody has made a request against it and looked at the response. So make one. This week. For every external thing your project needs:

# The dependency-verification drill — once per external dependency. Save the
# real output, date it, keep it.
curl -s -o /dev/null -w "%{http_code}\n" "https://<the-endpoint-you-plan-to-use>"

# Then answer, in writing:
#   Did it need a key? How long did getting one take?
#   What is the rate limit, and where is it documented?
#   What do the terms of service say about a student project?
#   What is the response when the thing I ask for does not exist?

Free tiers, quotas, and license terms change constantly, and without telling you. Never take a number from a blog post, a classmate, or an assistant. Read the vendor’s own page, this week, and write down what it said and the date you read it. In Week 5 you will cite that note in an architecture decision record; in Week 14 you will find out whether it was true.

And then there is the gate nobody writes down — Show: can a stranger watch it work in ten minutes without your narration? Week 16 is a thirty-minute presentation to people who have not seen your code. If the only way to appreciate your project is to explain the architecture, you have built something you cannot demonstrate — and that is not a presentation problem you fix in Week 15, it is a scoping problem you fix now. The evidence is ten numbered steps, written down, that produce something a person who does not know you would call working.

2.4 — Right-Sizing: The Arithmetic of 240 Hours

Now the division problem. Take it slowly, because it is the most valuable ten minutes in this book.

The course budget is 240 hours across 16 weeks. Here is where they go:

Read the bold line again. Sixty hours. One quarter of the course is construction, and that quarter includes Week 11, which is testing, and Week 9, most of which goes to the walking skeleton, continuous integration, and deployment plumbing rather than to features. So the number you are actually scoping against is:

About 45 hours of net feature construction. You can borrow up to roughly 15 more from Weeks 11 and 13, which puts the hard ceiling near 75 hours of construction, total — but every borrowed hour comes out of testing and documentation, which are worth real points in Week 16 and which nobody has ever finished in a hurry.

What does one feature cost? Not “the happy path in an editor.” A feature is a vertical slice: the interface a user touches, the handler behind it, the data access, the validation, the error path when it goes wrong, at least one test, and the line in the documentation that says it exists. In a stack you know well, budget 7 to 9 hours per slice; in a stack that is new to you, 12 to 20. Divide. Forty-five hours at eight hours a slice is five or six features. That is your entire capstone.

Now watch a normal first draft meet that number. Here is PantryPilot’s initial feature list, with the hours its owner first guessed beside the hours an honest vertical-slice estimate produces:

Forty-one hours felt like a comfortable semester. The honest number is 146 hours of features against a 45-hour budget — more than three times too big — and that is before the walking skeleton, continuous integration, and deployment. This is not a story about a careless student. It is the normal first draft. Kahneman and Tversky named it in the late 1970s: the planning fallacy, the reliable human tendency to estimate a task as if nothing will go wrong, even when you have never once had a task where nothing went wrong. Hofstadter’s Law, at the top of this chapter, is the same observation told as a joke.

The professional response is not to estimate better. It is to estimate in ranges and cut scope until the range fits. What Steve McConnell popularized as the cone of uncertainty says the same thing: an estimate made at inception — right now, today — is wide, roughly a factor of four in each direction in the usual rendering, and it narrows only as design decisions get made. Your Week-2 number is a range with a wide mouth. Your job is not to make it precise. Your job is to make sure that even its high end fits.

So PantryPilot got cut. The surviving scope:

Sixty-four hours against a 60-hour plan and a 75-hour ceiling. Right-sized, with no slack — which is exactly why the AI recipe feature is a Should, not a Must: the first thing built if Week 12 has room, and the first thing cut if it does not.

Notice the cleverest cut in that table. User accounts cost 15 hours and household sharing cost 12; replacing both with a single shared join code costs 9 and delivers what the users actually asked for, which was a shared list, not an identity system. The cost is real — anyone with the code gets in, and there is no per-person history — and it goes in the specification as an accepted risk, in writing, with the reason. That is a scoping decision. Deleting a feature because you ran out of time is not.

Coach’s Note — When you cut, cut features, never quality. A five-feature project with tests, documentation, and a working deploy scores far higher in Week 16 than an eleven-feature project with none of them — and it is also the one you can still fix in Week 15. Scope is the variable. Quality is a constant.

2.5 — The Three-Candidate Rule, and Why You Must Kill Two

Bring three candidates to the decision. Not one, not two. Three. One candidate is not a decision; it is an attachment. You will not see its flaws because you have nothing to compare them against, and every problem you hit in Week 10 will feel like the cost of doing business rather than a warning you ignored. Two produce a false binary — you will pick the one you already liked and use the other as a foil. Three forces something different: you cannot hold three projects in your head at once, so you are forced to write criteria down and score against them. The criteria are the point. The scores are just arithmetic.

Score before you fall in love. Here is the scorecard — five criteria, weighted, one to five each:

The maximum is 55, and that number means nothing on its own — it is not a grade, and a 47 does not beat a 44 in any meaningful sense. What the scorecard does is force you to notice that your favorite candidate scored a 1 on evidence a user exists, which no amount of enthusiasm fixes.

Then kill two, in writing. Each rejection gets a paragraph naming the gate it failed. That paragraph is not busywork; it is a message to the version of you who exists in Week 10 — tired, stuck on a bug, and suddenly convinced that Candidate B would have been so much easier. Here is what a real rejection reads like:

Rejected — StudyLoop (spaced-repetition study tool for the CS department). Failed the evidence gate. I talked to two students in the major; both already use an existing spaced-repetition tool and neither could name something it does badly. The genuinely hard part I was excited about — the scheduling algorithm — is a solved problem I would be reimplementing rather than solving, which makes it a poor answer to “what was the hard part?” in Week 16. The sizer put it at 103 hours against a 60-hour budget. If I revisit this, the trigger is finding a user with a need the existing tool does not meet; absent that, it stays dead.

Rejected — CampusRide (matching students who want to share a ride home over break). Failed on scope and on judgment. Matching, messaging, accounts, notifications, and real-time updates size at roughly 180 hours, three times the budget. Separately, and more decisively: a system whose job is to put strangers in cars together carries safety and liability obligations I cannot discharge as a solo student in one semester, and I am not willing to ship something whose worst-case failure is that kind of harm. This one is not deferred. It is closed.

That second rejection is worth studying. It is not a scope decision — it is a judgment decision, the kind no estimator and no assistant can make for you, and it is the sort of thing this course exists to teach. Some projects are the wrong size. Some projects are the wrong thing.

Coach’s Note — Write the rejections while you still like the rejected ideas. A rejection written after you have committed is a rationalization, and you will be able to hear the difference in your own voice when you reread it in October.

2.6 — Evidence a User Exists: Talking to One Human Being

Forty-five minutes this week will do more for your capstone than any other forty-five minutes in the semester. Find a person who has the problem and ask them about it. Not a person who likes your idea — your roommate will say your idea is great, because your roommate likes you. Find someone who has the problem, and then do something that feels deeply unnatural: do not pitch. Do not describe your app. Ask about their past.

That is the core discipline of Rob Fitzpatrick’s The Mom Test (2013), and the whole book is one insight: people will lie to you about the future to be kind, but they will tell you the truth about the past, because it already happened.

Five questions is enough: fifteen minutes of listening, thirty minutes of writing it up. Three things to listen for:

• A workaround. If they already do something clumsy about it — a whiteboard, a spreadsheet, a group chat, a stack of sticky notes — the problem is real. If there is no workaround at all, be careful: either the problem does not hurt enough to act on, or they are not the user.
• A number. Money, minutes, or a count. “About $40 last month” is worth more than “a lot.”
• Verbatim quotes. At least three, in their words, exactly. In Chapter 3 those quotes become requirements, and a requirement you can trace to a sentence a human being said is a requirement you can defend.

Write it up the same day, dated, with the quotes. That write-up is graded this week, and it is the single strongest thing in your Week-16 package that a fabricated project cannot produce.

One honest exception. If your project genuinely has no user but you — a developer tool you will use, a simulator, a research replication — say so plainly and raise the bar elsewhere: name the class of user, show the tool category exists, and produce a competitive scan of what is already out there. What is never acceptable is inventing a user. A grader can tell, and so can everybody else.

2.7 — Novelty Is Not the Bar. Completeness Is.

Here is the sentence students most need to hear in Week 2 and least want to believe: nobody is grading your originality.

Look at where the points live. Fifty percent of this course is the Week-16 submission, another twenty-five percent is the fourteen milestones that produce it, and that submission is graded on working software plus a requirements specification, a technical specification, decision records, a test suite with results, a defect log, an hours log, a README, a runbook, a handoff guide, a change log, an AI-usage log, a license, and a tagged release (Appendix C has the full rubric). Count how many of those lines reward inventing something nobody has built. Zero.

So “someone already built this” is not a reason to kill an idea. It is evidence the problem is real — somebody thought it was worth a company. The world is full of excellent software that is the fourth of its kind. What you are graded on is whether you can carry one system through a full life cycle and hand it to a stranger. The failure mode this protects you from has a name in this book: the ambitious ruin — a distributed, event-sourced, three-service architecture with no tests, no README, no deployment, and a demo that has to be restarted twice. Genuinely impressive in Week 6. Genuinely a zero in Week 16, because there is nothing to hand over.

That said, your capstone should have exactly one genuinely hard part. One. The thing you will be proud of, that takes real thought, that you can talk about for ten minutes in Week 16 without slides. One hard part is a capstone. Four hard parts is a course you fail.

Pick your one hard part deliberately, name it in the scoping memo, and then make everything else in the project as boring as you can possibly stand.

2.8 — Should Your Project Use AI? Honest Feature vs. Garnish

You are not required to put AI in your capstone. Let that land: a project with no model call in it can earn full marks. What you are required to do is make the decision on purpose and defend it. An AI feature is honest when it passes five tests; if it fails any one of them it is a garnish, and a garnish costs you real hours to earn no points.

1. Necessity. Does it do something the user needs that a deterministic approach cannot do acceptably? “Rank recipes by how many ingredients you already have” is arithmetic, not AI. “Suggest a plausible meal from an odd assortment of ingredients” is genuinely a language problem.
2. Evaluation. Can you tell whether an output is good, mechanically, on more than one example? If you cannot measure it, you do not have a feature — you have a demo that works when you are driving.
3. Fallback. What happens when the provider is slow, down, rate-limited, or wrong? Every AI feature needs a non-AI path, and your Week-16 demo needs to survive the conference-room wifi.
4. Cost and cap. Do you know your cost per call, and have you set a hard spend cap? Pricing and free-tier terms change; read the vendor’s current page yourself and write down the date. Then put a cap on the account. Students have run up real bills on a runaway loop.
5. Data. Is what you are sending the provider something you are permitted to send? If the answer involves anyone else’s personal data, the answer is probably no.

Here is the same feature written both ways. Garnish:

The app will include an AI assistant that users can chat with about their pantry.

No user need, no acceptance criterion, no evaluation, no fallback, no cap. It exists so the word “AI” appears on the title slide. Estimated cost: fifteen hours. Estimated value: zero. Honest:

FR-14 (Should). Given a pantry containing at least four items, the Cook Tonight view returns three recipe suggestions in under four seconds. Every suggestion names only ingredients present in the pantry plus a fixed pantry-staples list (salt, oil, flour, rice). Evaluation: a fixture of 20 saved pantry states; a suggestion passes if it introduces no ingredient outside those two sets; the feature is accepted at ≥ 17/20. Fallback: if the provider errors or exceeds four seconds, the view falls back to a rules-based ranking over a local recipe table, and the interface labels the result Suggested from your pantry either way. Cost: one call per view; account cap set; costs recorded weekly in the hours log.

That is a specification. It has a trigger, a measurable outcome, a pass threshold, a fallback, and a budget. It is also, honestly, 18 hours — which is why PantryPilot marks it Should and builds it only if Week 12 has room.

Coach’s Note — An AI feature adds a dependency you do not own to a demo you cannot reschedule. If you build one, build the fallback path first and record a fixture of real responses in Week 12. On presentation day you want a switch you can flip, not a prayer.

2.9 — The Assistant as Sparring Partner and Feasibility Skeptic

An assistant is genuinely good at four things this week, and dangerous at a fifth. Where it earns its keep:

• Expanding a problem into a candidate feature list. Give it your problem statement, ask for fifteen features a system solving it might have, and then cut — it is far easier to delete than to invent.
• Naming what you forgot. Models are very good at “you did not account for password reset, database migrations, timezone handling, empty states, or the case where the API returns 404.”
• Enumerating failure modes. “List five ways a barcode lookup API fails in production and what handling each costs” is a question it answers well and you would answer incompletely.
• The pre-mortem. Gary Klein’s technique, and it works beautifully with a model: it is Week 16 and this project failed; write the three most likely post-mortems. Every credible post-mortem converts directly into a risk with a trigger.

Where it fails, every time: it cannot estimate your hours. It does not know how fast you are, what you already know, or that you have a networking exam in Week 10. Any hour number it gives you describes an average person who does not exist — use it to find tasks you missed, never to size them. And it will agree with you. Ask “is my capstone idea good?” and you get enthusiasm; ask leadingly enough and it will cheerfully agree that a 220-hour project fits in 60. It is trained to be helpful, and in this specific moment helpful and useful are opposites.

So do not ask it to judge. Make it argue:

Bad:   "Is this a good capstone project idea?"

Good:  "Here is my scope: <the five features, one line each>. Assume a single
        senior with about 45 hours of net feature-construction time, working in
        <stack>, new to <the one new technology>. List the ten tasks I have not
        accounted for. For each, give an hour estimate and one sentence on why
        students underestimate it."

Good:  "Argue that this project cannot be finished in 240 hours by one student.
        Be specific, cite the exact parts of the scope that make it impossible,
        and do not be encouraging."

Good:  "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."

Then verify. A model will confidently name libraries that do not exist, APIs that were renamed, and free tiers that ended. Every dependency it suggests goes through the Get gate in §2.3 — a real call, a saved response, a dated note — before it appears in any document you sign. Then log the session in docs/ai-usage.md the way you committed to in Week 1: what you asked, what it gave you, what you kept, what you changed. Ninety seconds, and it is worth points in Week 16.

Coach’s Note — The spine rule for this whole course, and you will hear it in every chapter: the assistant accelerates, the human decides, verifies, and is accountable. This week the judgment being tested is whether your project fits in your life. No model has ever known that about anybody.

2.10 — Writing the Scoping Decision Memo Your Future Self Will Thank You For

The artifact of Week 2 is a memo. It lives at docs/scoping-decision.md, and Chapter 3’s requirements specification will cite it in its first section. It is short — two pages is plenty — and it has nine parts: (1) the problem statement, in the frame from §2.1; (2) the user and the evidence, with the date of the conversation and three verbatim quotes; (3) the chosen scope — the Must features, with hour estimates, summing to a number that fits; (4) what you will not build, by name, at least eight items; (5) the two rejected candidates, each with the gate it failed; (6) the hour budget by phase, reconciled against 240; (7) the one hard part, and why it is hard; (8) the risks, and the trigger that will force a scope cut, with a date; (9) your name and the date.

Part 4 is the part students skip and the part professionals read first, for a plain reason: a feature you never wrote down is a feature you will “just add” in Week 12, while a feature on an explicit out-of-scope list is one you already decided about, once, calmly, in Week 2. That decision is worth ten hours later.

Now the promise this book makes — the same memo written badly, then well. Bad:

I decided to build PantryPilot because it is the most interesting of my three ideas and I think it will be a great learning experience. It will be a web app where users can track their groceries and get recipe suggestions using AI. I also considered a study app and a rideshare app, but PantryPilot seemed like the better fit for my skills. The scope is reasonable and I should be able to finish it in a semester. I plan to use a modern stack and follow best practices.

Everything wrong with it, in order: no user, no evidence, no cost, no numbers, no feature list, no boundary, no reason either alternative died, no hard part named, and a closing sentence — “should be able to finish” — that is unfalsifiable and therefore cannot be wrong, which is exactly why it is worthless. “Best practices” is filler. This memo commits its author to nothing, so it will protect them from nothing. Good:

Scoping Decision — PantryPilot Author: · 2026-09-08

Problem. Four students sharing an off-campus kitchen throw out food that expires unnoticed while buying duplicates of things they already have. One housemate counted roughly $40 discarded in March, mostly produce and dairy. Their current workaround is a dry-erase board on the fridge, abandoned after two weeks because updating it requires standing in the kitchen with a marker while carrying groceries.

Evidence. Interviewed R.M. (housemate, not a CS student) on 2026-09-04, 40 minutes, past-tense questions only. Quotes: “I bought a second jar of pesto because I couldn’t see the first one.” · “The board worked for like two weeks.” · “I mostly find out something went bad by smelling it.” Full write-up in docs/interviews/2026-09-04-rm.md.

Chosen scope (Must, 44 h of features). (1) Add an item manually — 7 h. (2) Add by barcode with manual fallback — 14 h. (3) Pantry list with edit / consumed / discarded — 8 h. (4) Expiring-soon view, configurable window — 6 h. (5) Shared household via join code — 9 h. Plus walking skeleton and CI, 12 h, and deployment plus clean-machine test, 8 h. Construction total 64 h against a 60-hour plan and a 75-hour ceiling: right-sized, no slack.

Accepted tradeoff. No user accounts. A household is joined with a shared six-character code. This replaces 27 h of accounts-plus-membership work with 9 h and delivers what the users asked for — a shared list. Accepted cost: anyone holding the code has full access, and there is no per-person history. Recorded as an accepted risk; revisit only if a real user asks for per-person history.

Out of scope, and will not be built. Nutrition data · a mobile app · a shopping-list generator · waste analytics · barcode scanning from the device camera (manual entry of the number instead) · recipe import from URLs · notifications or email · multi-household support · offline mode · anything with a password.

Should (built only if Week 12 has slack). FR-14, the AI Cook Tonight suggestion — 18 h, with the evaluation, fallback, and spend cap specified in docs/requirements.md. First thing cut.

Rejected: StudyLoop. Failed the evidence gate — two interviewees already use an existing tool and could not name a weakness. Sized at 103 h. Revisit only on finding an unmet need. Rejected: CampusRide. Failed scope (≈180 h) and judgment: a system that puts strangers in cars carries safety obligations I cannot discharge solo in a semester. Closed, not deferred.

The one hard part. Barcode-to-product resolution. Third-party product data is incomplete, expiry dates are never returned, and the feature must degrade gracefully to manual entry without the user perceiving a failure. This is the piece I will be able to talk about for ten minutes in Week 16.

Risk and the trigger. Highest risk: the product-lookup API’s free quota or terms change mid-semester (read 2026-09-05; terms noted in docs/adr/0002-product-lookup-api.md). Scope-cut trigger: if the walking skeleton is not running in continuous integration by the end of Week 9 (2026-10-27), feature 5 (household sharing) is cut first, then feature 2 falls back to manual entry only. Decided now, in advance, so I do not have to decide it while panicking.

Every sentence in the good version can be checked by someone else. That is the whole difference: a document nobody can disagree with is a document nobody can rely on. Start from code/scoping-decision-memo.md — the blank template, with the nine sections and the prompts for each. Fill one code/idea-canvas.md per candidate first; the memo assembles from the three canvases in about an hour.

2.11 — Interactive Lab: The 240-Hour Scope Sizer

Embedded on this page is The 240-Hour Scope Sizer. Use it now. You describe a candidate with sliders and switches — how many user-facing features, how many external integrations, how complex the data is, how many technologies are genuinely new to you, and whether it needs accounts, persistent storage, and a deployment somebody else can reach. It returns an hour range with a confidence band, a breakdown by life-cycle phase, and a blunt verdict — too small to defend, right-sized, or you will not finish this — plus the two specific cuts that would bring it into range. Do this with it:

1. Run all three candidates. Record each range and verdict in your scorecard. Do not run only your favorite.
2. Run your favorite twice: once as you want to describe it, and once as you would describe it to somebody who is going to hold you to it. If the two runs differ, the second one is true.
3. Apply the two cuts it names and re-run. Watch which lever actually moves the number. It is almost never the one you expected — for most student projects, novelty load and integrations dominate feature count.
4. Then estimate the same candidate by hand, bottom-up, feature by feature, the way §2.4 does it. That is Rep 7.

Step 4 is the point of the lab. You now hold two independent estimates produced by different methods, and they will disagree — probably by 20 to 40 percent. That disagreement is the lesson, not a bug. Professional estimating is exactly this: two methods, a gap, and a conversation about which assumptions differ. If your two numbers are within about 30 percent of each other, you have a defensible number. If they differ by more than a factor of two, one of them is wrong and you need to find out which now, in Week 2, when finding out is free.

The sizer’s model is a heuristic calibrated to one senior working roughly fifteen hours a week; it knows nothing about you. Treat it as a skeptical colleague with a spreadsheet, not an oracle — and to run the same model offline against all three candidates at once, code/size_check.py does exactly that from the sample data in code/candidate-scorecard.csv.

2.12 — How Do You Tell a Worthy Work From a Vain One?

“Unless the LORD builds the house, those who build it labor in vain. Unless the LORD watches over the city, the watchman stays awake in vain.” (Psalm 127:1, ESV)

Read that verse carefully, because it is almost always read wrong. It does not say do not build. The house still gets built, and by builders. The watchman still stands his post. The psalm assumes ordinary, competent, exhausting human work and does not disparage a minute of it. What it denies is self-sufficiency — the idea that effort alone founds a thing, that if you are diligent enough and clever enough the result is guaranteed and it is yours.

That word vain is worth sitting with. In the sense the psalm carries, it means empty — labor that occurs and produces nothing that lasts. Every engineer knows the feeling. The repository with 400 commits and no users. The rewrite that shipped the same features eighteen months later. The feature you argued about for three sprints that nobody ever clicked. The work happened; it was real work, real hours, real fatigue; it founded nothing. Ecclesiastes has the phrase for the taste it leaves: “a striving after wind” (Ecclesiastes 2:11, ESV).

So how do you tell a worthy work from a vain one, in Week 2, before you have built any of it?

Not by ambition. Genesis 11 is in the Bible partly as a warning about scoping. The builders at Babel had a genuine engineering achievement in front of them and a stated motive: “let us make a name for ourselves” (Genesis 11:4, ESV). The project was sized to the reputation its builders wanted, not to the need it served or the strength they actually had. That is precisely the capstone that consumes eleven weeks and ships nothing — a tower scoped by ego. You will feel the pull of it this week, in the exact moment you catch yourself asking not does this help anyone but will this look impressive.

Not by cleverness, either. Section 2.7 made the engineering case: completeness beats novelty, because completeness is what can be handed over. The theological case runs alongside it and is older. The Lutheran doctrine of vocation says something startling about ordinary work — that God provides for people through the ordinary labor of neighbors, and that the farmer, the nurse, the parent, and the programmer are all instruments of that provision when their work serves someone. On that account, a small tool that stops four students from throwing out $40 of food a month is not a modest project dressed up as a grand one. It is a real one, at its real size, doing exactly what work is for. “Whatever you do, work heartily, as for the Lord and not for men” (Colossians 3:23, ESV) — and note what that verse governs. Not the scale of the work. The manner of it.

Three tests, then, that survive contact with a real project. Does anyone besides you need it? Not “would anyone like it.” Need it. You will find out by talking to one human being (§2.6) — which is why that exercise is graded, and why fabricating it would be worse than skipping it.

Will it exist after you are gone? The handoff question, and Week 14’s whole subject. Software that only its author can run is software that dies at graduation. Paul’s instruction to Timothy — entrust what you received to faithful people who will be able to teach others (2 Timothy 2:2) — is, among other things, a remarkably good description of a handoff guide.

Would you still be glad if your name came off it? The Babel test, run in the mirror. If the value of the project collapses when the credit does, you have been building a tower. This is not an argument against being proud of your work; it is an argument about why you would be.

One last thing, and it is the part of Psalm 127 that comforts rather than warns. If the founding does not ultimately rest on your effort, your effort does not have to be perfect. You are going to make a scoping mistake this week — everyone does. You will pick a hard part that turns out to be harder, or estimate a feature at eight hours that costs twenty. The psalm’s answer is not “try harder” but something closer to you were never the foundation anyway. Count the cost honestly — that was last week’s verse, Luke 14:28, and sitting down to count is an act of humility, not pessimism — then build with your hands open. The work you can do faithfully in 240 hours is enough. It was never going to be 2,400.

2.13 — Common Pitfalls

Pitfall: The technology-first idea. Example: “I want to build something with Kubernetes and a vector database.” The problem gets invented afterward to justify the stack, and it shows. Fix: Write the problem statement first, with the which costs line filled in with a number. If your favorite technology is still the right answer three weeks from now, defend it in an architecture decision record in Week 5 — where that argument belongs.

Pitfall: Scoping by feature-list length instead of by hours. Example: A tidy list of twenty-two features with no hour attached to any of them, which feels like a plan. Fix: Put an hour estimate on every single line, using vertical slices — interface, handler, data, validation, error path, test, documentation. Sum it. Compare it to 45. Cut until it fits, then cut one more.

Pitfall: The assumed dependency. Example: “I’ll use the university’s course catalog API.” Nobody has confirmed it exists, is public, permits student use, or returns what you need. Fix: Make one real call this week, save the response, and note the date, the rate limit, and what the terms say. An unexercised dependency is not a dependency; it is a wish with a URL.

Pitfall: Running two decoy candidates. Example: Your real idea plus two you would never build, scored so the winner is preordained. Fix: Every candidate must be one you would genuinely accept if the scorecard chose it. Score all three before you let yourself have a preference — and if you already have one, score the other two first. (The mirror-image pitfall: killing a good idea because “three apps already do this.” Existing solutions are evidence the problem is real. Novelty is not on any rubric line in this course; completeness is on nearly all of them.)

Pitfall: The AI garnish. Example: A chat box added to the side of the application with no acceptance criteria, no evaluation, no fallback, and no cost cap — but “AI-powered” now appears on the title slide. Fix: Apply the five tests in §2.8. If it fails any of them, cut it, and say in the memo that you cut it and why. That sentence is worth more in Week 16 than the feature would have been.

Pitfall: Scoping the demo instead of the system. Example: A plan that produces a beautiful five-minute walkthrough and no tests, no README, no runbook, and no deploy. Fix: Budget the non-feature hours first — they are 180 of the 240 — and scope features into whatever is left. The demo is 10% of the grade. The repository behind it is 50%, and the milestones that built it another 25%.

2.14 — Where Your Hours Went This Week

Fifteen hours, honestly accounted. Yours will differ — log the real numbers, not these.

If you spent five hours browsing project ideas and one hour writing, flip that ratio next week. Reading about projects feels like progress and is not. The memo is the work.

2.15 — Reps

The reps are in the exercises — twelve of them, building the milestone piece by piece, so that by Rep 12 the memo mostly writes itself. A preview:

• Rep 1 — write ten problems in one line each, with every technology noun banned.
• Rep 4 — interview one human being with five past-tense questions and capture three verbatim quotes.
• Rep 5 — prove every external dependency exists by making one real call and saving the response.
• Rep 7 — estimate your chosen scope bottom-up by hand, then reconcile it against the sizer.
• Rep 11 — kill two candidates in writing, each with the gate it failed.

Then take the on-page Check Your Reps quiz. Five questions, scored instantly, ungraded, and retakeable — it is the rehearsal. Week 2 Quiz in Canvas is the one that counts, drawn from a larger pool over the same material. Together the weekly quizzes and the Week-8 checkpoint are 15% of your grade, and they are the early-warning system that tells you and your instructor whether you actually did the week.

2.16 — This Week’s Milestone

Milestone 2 — Milestone 2: Idea Portfolio & Scoping Decision. Three completed candidate canvases, one user conversation written up, a dependency-verification table, a bottom-up hour estimate, and the scoping decision memo at docs/scoping-decision.md.

Say the grading contract out loud one more time, because Week 2 is where students first talk themselves out of it. The milestones are graded twice. They carry 25% of the course grade on their own, and the artifacts they produce are then graded again inside the 50% final — because the milestones are the final deliverable, produced one week at a time. Skipping this week costs you twice: the milestone points now, and the same artifact points again in a week when you have no hours left to earn them. Appendix C has the pace table; check yourself against it on Sunday.

2.17 — Coach’s Final Word

Two weeks ago you had a course. This week you have a project — and, more importantly, two projects you decided not to build, for reasons you wrote down. That is the part that will surprise you later. The scoping decision memo is not really about the idea you chose; it is about the boundary you drew around it, in writing, while you were calm. In Week 10, when a feature seems obviously worth adding and it is 11 p.m. and you are certain it will only take two hours, you will not have the judgment you have right now. Your only defense will be a sentence you wrote in September that says I am not building that, and here is why.

So make the boundary real. Fill in the number on the which costs line. Talk to the human being. Make the API call. Do the division problem — sixty hours, minus the plumbing, over eight hours a slice — and let the answer be uncomfortable, because it is uncomfortable for everyone and only some people listen. Then kill two ideas you like, and go build the one that is left.

See you on Monday.

Up next: the exercises — twelve reps that assemble the memo · Milestone 2 — Milestone 2, the Idea Portfolio & Scoping Decision · then Chapter 3, where the analyst’s hat goes on and the scope becomes requirements a stranger could verify. Reference: Appendix A (workbench), Appendix B (document kit), Appendix C (grading contract), Appendix D (fifty sized ideas), Appendix E (glossary). Previous: Chapter 1.