PHASE TWO — BUILD.

//Vertical slices#

I build one complete screen at a time — every state, real data, keyboard and screen reader behaviour included — before starting the next. It feels slower for the first two weeks and is considerably faster by week six, because the unpleasant discoveries surface while there's still room to respond. Building all the happy paths first and then retrofitting error states is how projects end up with a final third that's entirely unplanned work.

//Visibility#

There's a deployed preview from day two, updated on every push. Two calls a week: one to review what's built, one to unblock decisions. Between those I work asynchronously and will send a branch rather than a summary. Written status reports are a substitute for access, and access is better.

When something takes longer than estimated you hear it the week it happens, not at the end of the phase. This is the single most reliable predictor of whether a project stays pleasant — bad news early is a scheduling problem, bad news late is a trust problem.

//Scope changes#

Expected, and handled the same way each time. A change gets written down with an estimate and a note on what it displaces, because capacity in a phase is fixed and something has to move. Most changes are worth making; the discipline is making the trade explicit rather than absorbing it silently and quietly slipping the date.