Day 91 final demonstration and next roadmap

Why this matters

Ninety days ago you drew five boxes on paper and traced one click through them. Today you will trace a click through a system you built, deployed, and can change while someone watches.

That is the whole point of this last hour. Not a celebration — a demonstration. The strongest proof of completion is that you can explain, modify, test, deploy, and maintain the app. Five verbs. A large repository proves none of them, and neither does a screenshot.

What ownership actually means

Run yourself against the five verbs honestly, because they are what an interviewer, a teammate, or next year's you will actually probe:

• Explain — trace any request from the click to the database row and back, naming your own files.
• Modify — make a small change, in the right place, without breaking a neighbour.
• Test — say which test would catch a given bug, and run it.
• Deploy — ship a release and confirm it is healthy.
• Maintain — restore a backup, read the logs, and name what is unfinished.

Where a verb is shaky, that is not a failure. It is your first entry for the 90-day plan you write at the end of today.

The technical walkthrough

Ten minutes, in this order, with a budget so you do not spend six minutes on the login screen.

Min	Section	What you say
0–1	Problem and user	Who this is for, what they did before it existed
1–3	Architecture and a request trace	One click, every hop, in your real file names
3–4	Data model	Tables, the key relationship, one constraint and why
4–5	Security	Where authentication and authorisation are enforced, and why on the server
5–6	Tests and deployment	What is covered, what runs on release, how you roll back
6–7	The AI feature	What it does, where the key lives, what happens when it fails
7–9	One live code change	Make it, run the check, show it working
9–10	Limitations and next	What is unfinished and what you would build next

The request trace is the heart of it, and it is Day 1's diagram with your names filled in: button in RecordForm.tsx → POST /api/records → validation in records.ts → the query in queries/records.ts → row inserted → JSON response → the list re-renders. Six hops. If you can say those out loud without opening the files, you have the mental model this course was built to give you.

Live debugging

The live change is the part nobody can fake, which is exactly why it belongs in the demo. Ask someone to break something small in your app while you look away — a renamed field, a flipped comparison, an inverted status filter — and fix it while narrating.

The method you have been building since Day 24:

1. Reproduce it. See the failure yourself before touching anything.
2. Read the actual error. Word by word, and say where it came from: browser console, network response, or server log.
3. One hypothesis at a time, stated out loud: "if the field name changed, the response will have created_at and the component reads createdAt — check the Network tab."
4. Test the cheapest hypothesis first.
5. Verify with evidence, not with the absence of an error message.

Saying "I don't know yet — here is how I'll find out" is a strong answer. Silently guessing and changing three things is the weak one, whether or not it happens to work.

Explaining tradeoffs

Every decision in your project cost something. A senior engineer is recognisable by being able to name the cost, not by claiming there wasn't one. Use one sentence shape:

"I chose server-side sessions over JWTs because logout had to take effect immediately. The cost is that sessions live in process memory, so a restart signs everyone out and a second instance would break login. I would revisit it when the app needs more than one instance."

Decision, reason, cost, trigger to change. You already wrote three of these on Day 90 — read them aloud once and they become answers rather than documents. "It's the best practice" is not a tradeoff; it is a citation of an argument you did not make.

A 90-day plan that is real

Now the harder question: what next. A useful plan has three months, one theme each, and each theme proved by an artifact rather than by hours spent.

Choose themes from your own gaps, not from a list of trendy tools. Ranked by how often they actually matter:

• The gap in your five verbs. If deploying is still shaky, month one is deployment.
• Depth in one layer you only skimmed. SQL and query plans, or React rendering, or HTTP and caching. Depth in one beats a tour of five.
• The maintenance loop. Add automated tests to something you did not write; take a real feature request end to end.
• Something adjacent that compounds. Accessibility, CI pipelines, observability, or the domain your users work in.

Write it as three lines, each with a finish condition: "Month 1: CI. Done when every push runs lint, typecheck, and tests automatically and a red build blocks merge."

Walkthrough

Rehearse once, alone, with a timer and a written checklist — docs/demo-checklist.md, one line per row of the table above.

npm run check
curl -s -o /dev/null -w "%{http_code}\n" https://your-app.example.com/healthz
git log --oneline -5

200

Checks green, production healthy, and recent commits you can describe. Now run the ten minutes against the timer. Where you overrun, cut words, not sections — the AI feature and the live change are the two nobody will let you skip.

Your turn

1. Write docs/demo-checklist.md from the table above, with the minute budget.
2. Rehearse the full ten minutes alone, timed. Note every section you could not explain without reading, then go and read it.
3. Deliver the demo to a real person — a friend, a colleague, a camera. Record it if nobody is available; watching yourself is uncomfortable and effective.
4. Do a live change during the demo: a small feature or a fix to a fault someone planted. Narrate the debugging. Run the checks before you call it done.
5. Answer three tradeoff questions in the decision–reason–cost–trigger shape.
6. Write docs/next-90-days.md: three monthly themes, each with an artifact and a finish condition, plus the monthly no-assistance rebuild.
7. Confirm the four deliverables exist: deployed app, repository, demo checklist, and the 90-day plan.

Common pitfalls

• Demoing the UI instead of the system. Clicking through screens shows nothing about how it works. Trace a request and name the files.
• Hiding the unfinished parts. Someone will find them in five minutes and now they doubt everything else. Lead with your limitations list; it reads as competence.
• A plan measured in hours. "Study SQL for 20 hours" cannot be finished. "Add three indexes justified by query plans" can.
• Rehearsing the words instead of the system. A memorised script collapses at the first question. Rehearse the trace, then speak plainly.

Verify it yourself

Open today's reference, the Codex CLI documentation, one more time — but read it differently than you did in Week 5.

1. Find one capability you never used in this course. Decide, in writing, whether it would have made your work better or only faster, and whether you could still have explained the result.
2. Locate what it says about giving a project its own instructions. Compare it to the file you wrote on Day 81, and update that file with one thing you learned in Weeks 12 and 13.

Then take five minutes with your Day 1 notes. The five boxes are still the right diagram — you have simply filled every one of them in, plus the parts nobody draws: the migration that must not drop a column, the error state that offers a way out, the key that stays on the server, the backup you actually restored. Nothing here was magic; it was ninety-one hours of reading the real evidence before deciding. That method is what you keep. The app is just the proof.