This is the long stretch — eight hours, the bulk of the day, and the part where the sprint is usually won or quietly lost. It is lost by building outwards: a beautiful header, then a settings page nobody will open, then the actual product at hour twenty. It is won by building the spine.
What the spine is
The spine is the single path from a stranger arriving to the promise being kept. Three to five steps, no branches:
- Land on the page and understand what this is
- Give the one input the product needs
- Wait, with something honest on screen
- See the result
- Do something with it — copy, download, share
That is the entire product for today. Everything that is not on that path is on the kill list, including things that feel mandatory. Settings are not on the path. Accounts are not on the path. An about page is not on the path.
Write your five steps down before you write any code. If your list has eight steps, you are building two products and have not finished cutting scope.
Build it end to end, ugly
Get all five steps working before you improve any of them. Unstyled headings, browser-default buttons, a result rendered as raw text — it does not matter. What matters is that at hour ten, someone could complete the journey.
This ordering feels wrong and is correct. A product with a complete ugly spine is shippable at any moment after hour ten; a product with two gorgeous steps and a missing middle is shippable never. You are converting the sprint from "will I finish?" into "how good can I make the thing I have already finished?" — and that is a far better question to be asking with fourteen hours gone.
Attack the risky part first
Within the spine, there is one step you are least sure about: the API that might not return what you need, the parsing that might be messy, the model output that might be unusable. Do that one first, at hour six, on the smallest possible scale.
Not the polished version — the version that proves it works. One hardcoded input, one console log of the output. If it works, the rest of the day is execution. If it does not, you have found out at hour seven, when you can still change the promise, rather than at hour nineteen, when you cannot.
Which model, when
This stretch is where most of the day's token spend happens, so the Opus/Sonnet split from Lesson 4 stops being theory and starts being your budget.
Bring Claude Opus 5 in three places: the plan for the spine before any code, the risky step above, and any bug that has already survived two attempts. Three or four sessions, each one deciding something.
Run everything else on Claude Sonnet 5 — the routes, the forms, the data layer, the hundred small corrections. That is the bulk of the hours and almost none of the difficulty.
The tell that you have it wrong: if you are asking the heavier model to apply a decision you have already made, you are paying for reasoning you do not need. Decisions upward, execution downward.
Working rhythm
- Commit every time a step works. Small commits are free undo, and you will need one.
- Deploy every two hours. Production breaks in ways local does not; find out in daylight.
- Keep a
LATER.md open. Every idea that arrives mid-build goes there in one line and leaves your head immediately. This file is the pressure valve that lets you stay on the spine without losing the thought.
- Timebox anything that stalls. Twenty-five minutes on a bug with no progress means the approach is wrong. Stop, and take the ugly path: hardcode it, swap the library, or cut the step.
The hour-fourteen checkpoint
Stop, deploy, and walk the spine yourself as a stranger would. Ask one question: can someone go from landing to result without me?
If yes, you have a product. The remaining ten hours make it look and read like one, and you are comfortably ahead.
If no, you cut now — not later. Remove the step that is not working, simplify the promise to match what does work, and update SCOPE.md. A product that keeps a smaller promise is a launch. A product that keeps a larger promise badly is a demo, and demos do not get shared.