Chapter 15 — The Thirty-Minute Case

“For a successful technology, reality must take precedence over public relations, for nature cannot be fooled.” — Richard P. Feynman, Appendix F, Report of the Presidential Commission on the Space Shuttle Challenger Accident (1986)

“Let another praise you, and not your own mouth; a stranger, and not your own lips.” — Proverbs 27:2 (ESV)

Why This Matters

Fourteen weeks ago you had an idea and an empty repository. Last week you tagged v1.0, wrote the runbook, and packed a handoff guide for a successor who does not exist yet. The software runs on a machine that is not yours. The documentation exists. The work, for practical purposes, is done.

And now you have to explain it to people who have not read a line of it.

This week you wear the last hat the course hands you: the presenter. In industry this hat has a dozen names — the sprint review, the demo day, the customer readout, the steering-committee update, the architecture review, the postmortem to a VP. Every one of them is the same shape: you have a fixed and cruelly short amount of time, an audience that did not build the thing, and a decision riding on whether they understand it. Engineers who cannot do this get overruled by engineers who can, and the better system loses. That is not a complaint about the world; it is a description of it. Learn the skill.

Where are you in the life cycle? Past construction. Past verification. You are in delivery — the transition phase, where the artifact stops being yours and starts being theirs. Delivery has two halves: the thing you hand over (Week 16’s repository) and the account you give of it (this week’s thirty minutes). The presentation is worth 10 percent of your course grade, and unlike every other component it happens exactly once, live, with no resubmission. You cannot patch a talk at 11:58 p.m.

Here is the thing nobody tells seniors before their first capstone talk: the presentation is not a summary of your work. It is a separate deliverable, built from your work. Students who understand this open their repository, mine it for evidence, and construct a case. Students who do not understand it open a blank slide deck at 9 p.m. the night before and try to remember what they did in October. The first group presents a project. The second group presents a memory of a project, and memories are vague, so the talk is vague, so the questions are brutal.

The AI thread this week runs both ways, and one direction is a trap. As a tool, an assistant is a genuinely excellent rehearsal partner — it will generate the hostile questions your committee will ask, faster and more mercilessly than a friend who likes you. As a workload problem, you are about to present work that an AI helped you produce, to a room that will ask you exactly which parts. Your docs/ai-usage.md is the answer to that question, and you had better know what is in it. And the spine rule holds harder here than anywhere else in this book: you stand at the front of the room. Every number on every slide is a claim you are personally making. “The assistant generated that slide” is not a defense; it is a confession.

Which brings us to the week’s real question, the one underneath all the run sheets and slide templates: how do you tell the truth about your own work? You are required to advocate for it — that is literally the assignment — and Proverbs says let another praise you, not your own mouth. Those two things sound like they cannot both be true. They can. Working out how is the most valuable thing in this chapter, and it is worth more than the grade.

15.1 — What a Capstone Committee Is Actually Listening For

You will be tempted to think your audience is listening for impressiveness. They are not. They are running a checklist, mostly unconsciously, and it looks like this:

Notice what is not on that list. Nobody is scoring your color palette. Nobody cares that you learned a framework — everyone in the room has learned a framework. And nobody, ever, is impressed by line count. Notice also the shape of the list: it is the arc of this entire course. Problem, user, requirements, decision, build, evidence, honesty. Your talk should walk that arc, because the arc is the curriculum and because the committee’s checklist runs in that order whether you cooperate or not.

Coach’s Note — A capstone committee is not a jury deciding whether you are talented. It is a group of engineers deciding whether they can trust what you tell them. Every choice in this chapter — the evidence slides, the recorded fallback, the “what did not get done” slide — is a move in that one game: be someone whose claims can be checked.

15.2 — The Arc: Problem, Users, Decision, Build, Evidence, Honesty

There is exactly one narrative shape that works for a technical talk about a system you built, and it is not chronological. Do not tell the story of your semester. Nobody wants the story of your semester.

Tell it in this order:

1. What it is — one sentence, ≤ 25 words, no jargon. Front-load this. If a stranger cannot restate it after your second slide, you have lost the room and will not get it back.
2. The problem and the user — one specific person or group with a specific pain. A number is worth ten adjectives.
3. What you committed to — the scope you signed up for, in requirement IDs, and what you deliberately cut.
4. How it is built — one diagram. Components and responsibilities, not classes.
5. The two decisions that mattered — with the alternative you rejected and what your choice cost you.
6. The demo — the software doing the thing, on purpose, against seeded data.
7. The evidence — tests, defects, measured non-functional numbers, hours.
8. What did not get done — named, dated, reasoned, costed.
9. What you would do next — three ranked items, straight out of your handoff guide.

Notice how much of that talk you have already written. Item 1 is the first line of docs/requirements.md. Item 3 is your MoSCoW table. Item 4 is the diagram in docs/architecture.md. Item 5 is two ADRs. Item 7 is your test results, defect log, and hours log. Item 9 is the “next three tasks” section of docs/handoff.md. The deck is an index into artifacts you already own. If you find yourself inventing content for a slide, stop — either the artifact is missing (fix that first, it is worth 50 percent) or the slide should not exist.

Coach’s Note — Build the deck with your repository open on the other monitor. Every slide gets a source. A slide with no source is a slide you will not be able to defend, and it is exactly the slide the sharpest person in the room will ask about.

15.3 — Allocating Thirty Minutes, Section by Section

Thirty minutes feels enormous until you stand up. Then it evaporates. The only defense is to spend it on paper first.

Here is the allocation I recommend, and I will defend every line of it:

Now the version I see every single year:

That second run sheet contains no requirements, no decisions, no evidence, and no honesty. It is thirty minutes about a project rather than thirty minutes of a project. It is also, in my experience, roughly a C.

Three allocation rules worth internalizing:

• The demo gets 7 minutes, hard. Under five and it feels like you are hiding something. Over ten and it swallows the case you were making. Seven with a scripted path and 2 minutes of slack is the sweet spot.
• Questions get at least 3 minutes of your thirty. If your institution runs Q&A outside the clock, wonderful — plan 3 anyway, because you will run over and that buffer is what saves you.
• Never plan to 30:00 exactly. Plan to 27:00 of content. Live delivery runs 10–20 percent longer than rehearsal for almost everyone, and the room will interrupt.

Build your own with code/talk-run-sheet.md — blank template plus a filled worked example.

15.4 — Slides That Survive a Bad Projector and a Nervous Presenter

Two hostile environments, one deck. The projector will be dimmer, smaller, and worse-calibrated than your laptop. And you will be nervous, which means you will read whatever is on the screen instead of saying what you meant.

Design for both.

The rules, and the reason for each:

The six-foot test: put your deck in presentation mode on your laptop, stand six feet back, and read it. Anything you squint at is invisible from the fourth row. Fix it now, not on stage.

Now the thing that actually separates decks — a decision slide, in both versions.

BAD:

Technology Choices
- We chose a modern, industry-standard stack
- React was selected for its powerful ecosystem
- SQLite was chosen because it is lightweight and easy
- The architecture is scalable and follows best practices

Thirty-eight words. Zero decisions. Every phrase on that slide would be equally true of a completely different project, which means it describes none. Worse: there is nothing here a committee can ask a follow-up about, so they will ask about something you did not prepare.

GOOD:

ADR-0003 — SQLite, not Postgres

Chose:      SQLite, single file, shipped in the repo
Rejected:   Postgres — needs a server my $0 hosting tier doesn't include
Because:    max 4 concurrent users (NFR-04); one writer is enough
Costs me:   no concurrent writes; migration is real work if usage grows
Evidence:   load test at 4 users, p95 = 180 ms  (docs/tests/load-2026-11-08.md)

Same choice. Five lines. A rejected alternative, a governing constraint with an ID, an honest cost, and a measurement someone could go check. This slide invites the follow-up question — and you already know the answer, because you wrote the ADR in Week 5.

That contrast is the whole chapter in miniature: adjectives are what you say when you have no evidence. The full twenty-slide skeleton, mapped to the run sheet and to the artifact each slide comes from, is in code/slide-outline.md.

Coach’s Note — Build back-pocket slides after slide 20 that you never show: the full requirements table, the traceability matrix, the risk register, the AI-usage summary, the deployment diagram. When a question lands and you can say “I have a slide for that” — that is the single most credible thing that can happen in a capstone talk.

15.5 — Demo Discipline: The Script, the Seeded Data, the Recorded Fallback

The live demo is the highest-variance seven minutes of your semester. It is also the only part of the talk that cannot be faked, which is exactly why it carries so much weight.

Treat it like a flight checklist, not a jam session.

Write the script. Not notes — a script. Numbered steps, with the exact action, the exact expected result, a seconds budget, the requirement ID it demonstrates, and what you do if it fails. The template and a worked example are in code/demo-script.md.

Compare:

BAD demo plan:

Demo:
- show the app
- add some food
- show the expiring soon page
- maybe show the recipe thing if it works

“Maybe” and “if it works” are how a seven-minute demo becomes eleven. There is no time budget, no data plan, no requirement mapping, and no failure protocol. When the barcode lookup times out — and one of them will — this plan has nothing to say.

GOOD demo plan (excerpt, PantryPilot — the running example; yours will differ):

| # | Do exactly this                | Expect exactly this                    | Sec | Satisfies | If it fails            |
| 2 | Click "Expiring soon"         | 3 items; yogurt red (expires tomorrow) | 40  | FR-07     | Say the number, skip   |
| 3 | Scan the printed barcode card | "Cannellini Beans, 15 oz" in under 2 s | 60  | FR-04     | Click "Add from cache" |

Every column is doing work. The expected result means you notice a wrong result instead of narrating past it. The seconds budget means you know at step 3 whether you are behind. The requirement ID means the demo is proving something specific rather than “look, it runs.” The failure column means the recovery is a decision you already made while calm.

Seed the data. Never type into a form on stage — typing is slow, typos are certain, and the room watches you make them. Ship a seed script, run it before the talk, and demo against known state. Use placeholder credentials only (demo@example.invalid and a seed-script password); a real key on a projector is a security incident with an audience.

Decide where the demo runs. Ranked, best to worst:

1. Local instance, no network needed. Fastest and safest. Say plainly: “this is running locally against seeded data.”
2. Deployed instance on your own hotspot. Realistic, and it proves Week 14’s work. Bring the hotspot.
3. Deployed instance on venue wifi. Convenient right up until it is not.
4. Anything that calls a third-party API live. Rate limits and outages do not care about your grade. Cache the response, or mock it, and say you cached it.

Record the fallback. This is not optional, and it is the single highest-return hour of your week. Capture the full demo path — screen and voice — with your operating system’s built-in recorder or a free, open-source tool such as OBS Studio (https://obsproject.com/). Then:

• Trim it to the demo length, no longer.
• Write down the timestamp of each step, and put those timestamps in the demo script’s failure column.
• Play it once with the wifi off. A recording that streams from the cloud is not a fallback.
• Put the file in the repository at docs/presentation/demo-fallback.mp4, or a link to it in docs/presentation/demo-script.md if the file is too large to commit.

The failure protocol, decided now: one retry maximum, name the defect out loud by its ID, cut to the recording at the written timestamp, keep talking, never debug on stage, never apologize twice.

Coach’s Note — A demo that breaks and is recovered in fifteen seconds costs you almost nothing — some committees quietly count it in your favor, because they have watched you handle a failure. A demo that breaks and is debugged for four minutes costs you the rest of your talk. The difference between those two outcomes is entirely a decision you make this week, in writing, while nothing is on fire.

15.6 — Showing Evidence Instead of Claiming Success

This is the section that separates a capstone talk from a product pitch, and most students skip it entirely.

An assertion is a sentence about your software. Evidence is an artifact a skeptic could go check. Your committee has heard a thousand assertions. Give them the second thing.

Every number in that right-hand column already exists in your repository if you did Weeks 7, 11, 13, and 14. You are not generating evidence this week. You are retrieving it.

Three evidence slides, in this order:

• Verification. Test counts, what kind, what is not tested. Naming your coverage gap out loud buys you more credibility than any number you could report.
• Defects. Opened / closed / open-by-severity, plus the worst open defect shown honestly, with your reasoning for leaving it.
• Non-functional. The measured number for your top NFR, and how you measured it. “Fast” is a feeling. “p95 of 380 ms over 100 requests, measured with this command, on this date” is engineering.

One rule will save you: never show a number you cannot source. Asked “where does 380 milliseconds come from,” the correct answer is a file path and a date — not “I think I measured that at some point,” which converts every other number in your deck into a guess.

Coach’s Note — The most persuasive slide in most capstone talks is the defect log. It is the slide that says: I looked for problems in my own work, I wrote them down, I fixed most of them, and I can tell you exactly which ones I did not. Nobody who was faking would build that slide.

15.7 — Saying What Did Not Get Done, and Why That Earns Points

Every student is convinced this slide will hurt them. Every experienced reviewer knows it is the one that helps most. Let me explain the mechanism, because it is not sentimentality.

Your committee will find the gaps. They have read the requirements you submitted in Week 3. They will notice that FR-15 through FR-19 never appeared. The only question is whether they hear it from you, framed and reasoned, or discover it themselves, in Q&A, unframed. Those two experiences produce very different grades:

• You say it: “Shared households across accounts is unbuilt. It needed the multi-user auth model I deferred in ADR-0004, and by Week 12 the integration work made that a 25-hour item I did not have. It is task one in the handoff guide.” → Assessment: this person understands their own project and can plan.
• They find it: “So… what happened to shared households?” “Uh — I ran out of time.” → Assessment: this person does not know where their hours went.

Same fact. Same software. Completely different talk. The slide has exactly three columns and one row per item — three items, maximum:

Notice what each row does. It names the requirement by ID, so it ties back to your spec. It gives a reason that is not “time” — time is the symptom, not the cause. And it puts a number on the remaining work, which is the clearest signal available that you can estimate. Two ways to get this wrong:

The apology tour. Opening with “I didn’t get as far as I wanted,” ending with “sorry it’s not more impressive,” and sprinkling “unfortunately” through the middle. This does not read as humility. It reads as a person asking the room to lower its standards, and the room obliges. State the gaps in the one slot built for them, in a flat voice, then move on.

The cover-up. Presenting only what works, hoping nobody opens docs/requirements.md. Somebody will. And the moment a committee catches one thing you glossed over, they start auditing everything else you said — including the parts that were true.

Coach’s Note — There is a difference between humility and self-deprecation, and only one of them is a virtue. Humility is an accurate account of what you did and did not do. Self-deprecation is an inaccurate one that happens to point downward. A lie about yourself is still a lie. Say the true thing, in a steady voice, and let it stand.

15.8 — Questions: The Ones You Will Get, and How to Say “I Don’t Know”

Q&A feels like the uncontrollable part. It is the most controllable part, because the questions are astonishingly predictable. Here are ten you should walk in with answers to — and prepare the ninety-second answer plus, where useful, a back-pocket slide:

1. Who is this for, and did you talk to any of them?
2. What was the hardest technical problem, and how did it end?
3. Why this stack? What would you pick if you started today?
4. What happens when the third-party API is down, or rate-limits you?
5. How do you know it works? Show me a test that fails if I break X.
6. What’s the worst code in the repository, and why is it still there?
7. What did you cut, and how did you decide?
8. How much of this did an AI write, and what did you verify?
9. Where do the secrets live, and what’s your privacy exposure?
10. If I hired someone Monday to take this over, what do they hit first?

Question 6 deserves a word, because students hear it as a trap. It is not. It is the single most reliable senior-versus-junior detector in the interview world. A junior says “I don’t think there’s any bad code.” A senior says: “The import pipeline in src/import/ — I wrote it in Week 10 before I understood the data, it has a 90-line function with three responsibilities, it is covered by four tests so I can refactor it safely, and it is item three in the handoff guide. It stayed because refactoring it was 8 hours and fixing DEF-041 was 2.” That answer is worth more than the code would have been.

Answering well is three moves:

1. Answer the question that was asked. Not the adjacent question you prepared for. If you are not sure what they asked, ask them — “Do you mean at the data layer or the API layer?” costs three seconds and prevents ninety wasted ones.
2. Answer it first, elaborate second. “Yes — and here’s why” beats two minutes of context ending in “so, yes.”
3. Stop talking. The most common Q&A failure is not a wrong answer. It is a right answer followed by sixty seconds of nervous elaboration that introduces a new weakness the room had not noticed.

And when you do not know, use the three-part form. It is short, it is honest, and it is the sound of a professional:

BAD: “Um, I mean, it should handle that, probably — I’d have to look, but I think the framework does it automatically? It’s pretty standard.”

GOOD: “I don’t know. What I do know is that I never load-tested past four concurrent users, so anything above that is untested. I’d find out by running the load script in docs/tests/ at 20 and 50 users — that’s about two hours, and it’s the first thing I’d check before anyone deployed this for real.”

Say it, bound it, and say how you would find out. That is a complete answer. Bluffing is not, and every engineer in the room can hear the difference — they have all bluffed, and they all remember getting caught.

Three things never to say: “that’s out of scope” as a dodge (say what you did scope, and why), “it’s just a class project” (you spent 240 hours — do not open by devaluing them), and any answer that begins with “well, technically…” while you buy time.

15.9 — AI in the Wings, Not at the Podium

Use an assistant hard this week — in the right places.

Where it earns its keep:

• The hostile committee. Paste your requirements spec, your architecture doc, and your README, and prompt: “You are a skeptical capstone committee of three senior engineers. Ask the fifteen hardest questions about this project. For each, name the artifact in the repository that would answer it.” You will get a rehearsal set in ninety seconds, and — this is the useful part — a list of questions your repository cannot answer. Those gaps are worth fixing before Week 16.
• Compression. Paste a wordy slide, ask for it in six bullets of seven words. This is editing, and it is a good use.
• The stranger’s read. Ask it to read your one-sentence description cold and restate what the software does. If the restatement is wrong, your sentence is wrong.
• The pre-mortem. “Here is my demo script. List every way this demo fails in a room with bad wifi.” Each failure mode becomes a row in the failure column.

Where it will hurt you:

• Letting it write the deck. A generated deck is fluent, confident, and full of claims you cannot source. The tell is always the same: a number or a superlative you cannot trace to a file in your repository. Under a question, you will discover on stage that you are defending a sentence you did not write and do not believe.
• Letting it write the narrative. It will reach for “seamlessly integrated,” “robust and scalable,” “cutting-edge.” Those are the exact adjectives §15.4 told you to delete. It writes them because they are common in its training data, not because they are true of your project.
• Prompting live during Q&A. No. Not once. The talk and the Q&A are yours alone. A student who types a question into a chat window at the podium has answered a different question than the one asked — can you account for your own work? — and answered it “no.”

The other side of the thread: presenting AI-assisted work honestly. Your committee will ask question 8, and they will ask it because the answer tells them what you actually learned. Prepare a back-pocket slide summarizing docs/ai-usage.md in five lines: where you used an assistant, what it produced, what you changed, how you verified it, and what you refused to delegate. The last line is the one that earns respect.

The honest version sounds like this: “An assistant scaffolded the API route handlers and drafted about 60 percent of my unit tests. I wrote the data model, the sync logic, and every requirement myself. I rejected its first caching design because it did not respect the API’s rate limit — that’s ADR-0003. Every generated test, I ran against a deliberately broken build to confirm it actually fails.” That paragraph is not a confession. It is a description of a professional working in 2026, and it is more impressive than pretending you typed every character.

The dishonest version — “I built all of it myself” — survives exactly as long as it takes someone to ask about the one file you did not read carefully.

Coach’s Note — The spine rule, one last time: the human stays in the loop where the judgment lives. An assistant can rehearse you, tighten you, and attack you. It cannot own a claim, and the entire thirty minutes is you owning claims. That is why it stays in the wings.

15.10 — Interactive Lab: The 30-Minute Talk Builder

Below this chapter on the website is The 30-Minute Talk Builder. Use it before you build a single slide.

Allocate minutes across the ten sections of a capstone talk — hook, problem, users, requirements, architecture and key decisions, live demo, verification results, what did not get done, lessons, and questions. The widget renders your allocation as a proportional timeline and warns you live when the plan is broken: a demo over ten minutes, a missing problem statement, architecture crammed into ninety seconds, no buffer left for questions, a total over thirty.

Then switch to rehearsal mode. It runs a countdown per section and records your actual pace against your plan, so you can see — in numbers rather than in feelings — which section you always overrun. It is almost never the one you expect.

What it teaches: that thirty minutes is a budget, not a container; that the sections you love will steal from the sections that score; and that the gap between planned pace and real pace is a measurable quantity you can shrink with reps. Do the lab, copy your allocation into code/talk-run-sheet.md, and rehearse against it.

15.11 — How Do You Tell the Truth About Your Own Work?

“Let another praise you, and not your own mouth; a stranger, and not your own lips.” (Proverbs 27:2, ESV)

Read that with a presentation due in six days and it sounds impossible. You are required to stand up and make a case for your own work. That is the assignment; it is also most of professional engineering. Do the Proverbs forbid the performance review?

No. The proverb is not a ban on speaking about your work. It is a claim about where credibility comes from — and if you understand it correctly, it is the most practical advice in this chapter.

Consider what actually happens in the room. When you say “my system is fast,” the only evidence in play is your enthusiasm, and enthusiasm is worth nothing because everyone presenting has it. When you show a measurement — p95 of 380 milliseconds, over 100 requests, on this date, by this command, in this file — the praise is no longer coming from your mouth. It is coming from the artifact. The measurement is the stranger. The test suite is the stranger. The demo, running live in front of people who did not build it, is the stranger. Your defect log, which volunteers evidence against you, is the most credible stranger in the room precisely because it has no incentive to flatter you.

So the proverb is not in tension with §15.6. The proverb is §15.6. Get out of the way and let the work speak, because a claim with a witness outlives a claim without one. Paul makes the same move in a harder register: “For it is not the one who commends himself who is approved, but the one whom the Lord commends” (2 Corinthians 10:18, ESV). Self-commendation is not merely distasteful; it is unreliable, because the one commending is the one with the most to gain.

Now the second half of the question, which is harder, because it cuts against the direction students actually fail.

Telling the truth about your own work has two failure modes, and both are lies. The first is obvious: inflation. Calling a prototype a product. Saying “it handles concurrent users” when you tested with four. Describing a feature as done when it works on your machine, once, if you click carefully. This is the failure everybody warns you about.

The second is the one nobody names: deflation. “It’s not really that impressive.” “I basically just followed a tutorial.” “Sorry, it’s kind of a mess.” Students perform this constantly, because it feels safe — if you say it first, nobody can say it to you. But look at it squarely: it is a false statement about a real thing. You spent 240 hours. You wrote a specification, made decisions and defended them, found and fixed nineteen defects, and produced software a stranger can clone and run. Saying that is nothing is not modesty. It is an inaccurate report, delivered to people who are relying on your report.

Luther’s explanation of the Eighth Commandment in the Small Catechism runs the other direction from where we usually apply it: we are not to lie about our neighbor, betray him, slander him, or hurt his reputation, but to defend him, speak well of him, and explain everything in the kindest way. We are trained to hear that as a rule about other people. But you are also a neighbor — you are the one you are currently speaking about — and false witness against yourself is still false witness. The commandment does not ask for a flattering account. It asks for a true one, given in the kindest way the truth allows.

Which gives you the standard for the whole thirty minutes, and it is beautifully simple: say what is so. Not the best version. Not the worst version. The accurate one — evidenced where evidence exists, bounded where it does not.

There is one more layer, and it is the reason this chapter closes here rather than at the rubric. Underneath both failure modes — the inflation and the deflation — is the same anxiety: my worth is riding on this. Inflate, and maybe they will approve. Deflate, and at least they cannot be disappointed. The Christian claim is that this is a question you were never supposed to be answering with a slide deck. Your standing does not hang on thirty minutes. It hangs on Christ, and it is settled. Which is exactly what frees you to be accurate — to show the defect log, to name the thing you did not build, to say “I don’t know” out loud in a graded room. Honesty is cheap for a person who is not trying to be justified by the presentation.

Faithfulness, not impressiveness, is the standard for a steward (1 Corinthians 4:2). Go be accurate. Let the work be the stranger who praises you, and let the parts that fell short be named plainly, because a person who tells the truth about small things is trusted with larger ones.

15.12 — Common Pitfalls

Pitfall: The demo eats the talk. Example: Fourteen unscripted minutes clicking through the UI, then racing through architecture and evidence in four, then no time for questions. Fix: Seven minutes, scripted, timed in rehearsal, with a KEEP/CUT marker on every other section. If the demo runs long, you cut inside the demo — not out of the evidence slides that carry the points.

Pitfall: Teaching the committee their own field. Example: Five minutes explaining what a REST API is, or what containers do, to a room of software engineering faculty. Fix: Assume your audience knows the technology and does not know your project. Spend the time on decisions, constraints, and evidence — the things only you can tell them.

Pitfall: Adjectives standing in for measurements. Example: “The system is fast, secure, and scalable” — with no number, no method, and no date anywhere in the deck. Fix: One measured number per claim, with the method and the date, sourced to a file. If you never measured it, say so: “I did not test above four concurrent users” is a stronger sentence than “it’s scalable.”

Pitfall: No recorded fallback, or a fallback that needs the internet. Example: The venue wifi captive portal eats the deployed instance; the backup video is a cloud link that will not load. Fix: Record locally, trim, store the file on the presenting machine, and play it once with the network disabled. Write the per-step timestamps into the failure column of docs/presentation/demo-script.md.

Pitfall: The apology tour. Example: Opening with “I didn’t get as far as I hoped,” saying “unfortunately” nine times, closing with “sorry it’s not more impressive.” Fix: All shortfalls live on one slide, in three factual rows, with reasons and costs. Then move on and do not revisit them. Accuracy, not self-deprecation.

Pitfall: Building the deck from memory the night before. Example: Slides full of vague recollections, one invented performance number, and no requirement IDs anywhere — because the repository was never open. Fix: Build the deck with the repository open. Every slide names its source artifact. If a slide has no source, either the artifact is missing (fix that — it is worth 50 percent) or the slide should not exist.

Pitfall: Reading the slides. Example: Turning to the screen and reciting your bullets verbatim while the room reads ahead of you. Fix: Fewer words on the slide, so there is nothing to read. Put your talking points in speaker notes or on an index card. Rehearse out loud at least three times — the third pass is where you stop reading and start talking.

15.13 — Where Your Hours Went This Week

Roughly fifteen hours, and almost none of them are coding hours. Week 15 is a feature freeze. You tagged v1.0 last week; from here you fix defects and you build the case. Adding a feature in Week 15 is how students arrive at Week 16 with a broken build and a talk they never rehearsed.

If deck-building runs well past four hours, the usual cause is that you are writing content instead of retrieving it — which means a Week-13 documentation gap just surfaced. Good. Fix the artifact, not the slide; the artifact is the one worth 50 percent.

15.14 — Reps

The reps for this week are in the exercises. As always, they are not warm-ups around the milestone — they are the milestone, built piece by piece. Preview:

• Rep 1 — the one-sentence description, ≤ 25 words, tested on a human who has never heard of your project.
• Rep 3 — mine your own repository for three evidence numbers, each with the file and date it came from.
• Rep 6 — write the demo script from code/demo-script.md, seed the data, and run it cold.
• Rep 9 — generate ten hostile questions with an assistant, answer each in one sentence, and mark the three you cannot answer.
• Rep 10 — three timed rehearsals logged to CSV, analyzed with code/pace.py. Report your drift in numbers. Do the on-page Check Your Reps quiz when you finish the chapter, then take Week 15 Quiz in Canvas — this late in the term the weekly quiz is the cheapest point on the board, and you should not be leaving it there. Then go do the reps.

15.15 — This Week’s Milestone

This week’s deliverable is Milestone 15 — Milestone 15: Presentation Deck, Demo Script & Rehearsal. You will build the deck, write and dry-run the demo script, record the offline fallback, prepare ten questions, and rehearse three times on a timer with the results logged.

Like every milestone in this course, it carries its own points in the 25% milestone bucket — and it is then graded twice more: once next week when you deliver the talk it produces (10 percent of the course), and once in the Week-16 documentation line for the artifacts that live in docs/presentation/. Skipping it does not save you points. It moves them to a week where there is no time left to earn them.

The full brief for the graded presentation itself — format, timing, what must be covered, delivery logistics, the recorded-fallback requirement, and the 100-point rubric — is The Capstone Presentation assessment that ships with this chapter, and it is summarized alongside the rest of the grading contract in Appendix C. Read it before you build a slide. Build the deck the rubric asks for.

15.16 — Coach’s Final Word

You have done the hard part. The software runs. The specification exists. The tests are green or honestly yellow. Somebody who has never met you could clone the repository and get it working, because you proved that last week on a clean machine.

All that is left is to be accurate about it for thirty minutes.

That is a smaller task than the one you just finished, and students still lose a full letter grade on it — not because they cannot present, but because they treat the talk as decoration on top of real work instead of as the delivery of it. Do not. Build the run sheet. Write the demo script. Record the fallback. Pull the numbers from your own logs. Say what did not get done, in a flat voice, with a reason and a cost. Prepare the ten questions. Rehearse three times, out loud, on a timer, and shorten it after each one.

And then walk into that room and let the work speak. You do not have to be impressive. You have to be true — and you have fifteen weeks of evidence sitting in a repository, waiting to praise you with a stranger’s voice.

One week left.

See you on Monday.

Up next: the exercises builds the talk rep by rep · Milestone 15 is Milestone 15 — the deck, the demo script, and three timed rehearsals · then Chapter 16 — delivery day, the final submission, and the end of the road. Reference appendices: Appendix B (the document kit), Appendix C (the grading contract and the presentation rubric), Appendix E (glossary). Previous: Chapter 14.