Break a Project Into Small Steps

Why this matters

Handing a whole brief to a tool and asking for everything produces the most impressive-looking failures in this program: a full app where nothing quite works and nobody knows which part broke it. Debugging five simultaneous changes means guessing; debugging one means looking. Small steps also match how attention works: each finished step is evidence the project is real, which is what keeps beginners going past week two. Plan first, then build the first working piece, then check it before touching step two.

Concepts

A good step has three properties: narrow (one change in one place), ordered (earlier steps never depend on later ones), and checkable (you know exactly how to confirm it worked). The bakery page becomes:

1. Page skeleton with three headings and placeholder text. Check: open it, see three headings.
2. Real text in all three sections from the brief. Check: read it, compare with the brief line by line.
3. Styling: readable on phone and desktop. Check: narrow the browser to phone width, everything fits.
4. Order form fields with labels, no sending yet. Check: every field labeled, tab order sensible.
5. Form shows a confirmation with the entered values. Check: fill it, see your own values back.
6. Orders saved in the browser across reloads. Check: reload, entries persist.

Notice the order rule inside the list: structure before text, text before style, display before storage. Each step's check takes about a minute and needs no expertise: open, read, narrow, fill, reload. When a step fails, the fault is inside that step, because everything before it already passed its check. That isolation is the whole point.

Risk early, polish late. If something is unknown (will the form work on old phones? does the layout survive long product names?), schedule it as step 2, not step 6. Unknowns discovered late force rework of everything built on top of them; discovered early they cost one step. Styling, animations and extra sections go last, always: polish on top of an unchecked foundation is how projects look finished while being broken.

When a step fails, shrink it. A failed step is too big by definition. Split it in half and do the first half. If that fails, halve again. "Add the form" failing becomes "add one labeled field", then "add the label". There is always a smaller step that works, and the working small step tells you exactly what the bigger one got wrong.

Worked example

Real input: "Build the bakery page this weekend." The all-at-once attempt returns a styled page with a form that sends nowhere, overlapping text on phones, and placeholder lorem ipsum in the hours section; fixing it takes longer than building it. The stepped version spends Friday on steps 1 to 3 (a readable page with real text), Saturday on steps 4 to 5 (a form that echoes entries), Sunday on step 6 (persistence). Each evening ends with a checked working thing. Same weekend, different project: one debuggable, one decorative.

Expected result: your version-one brief rewritten as 4 to 7 ordered steps, each with its one-minute check written down before building starts.

The common wrong move

Steps that are phases, not checks: "design phase, development phase, testing phase." Phases end with hope; steps end with evidence. If you cannot say how you will check it in one minute, it is not a step yet. Split it.

Lab and next step

Lab A05 sorts a feature pile into version one, later and out, stripping payment, login and reservation dependencies from the first release. Next, lesson 8 replaces "make it nice" with measurable acceptance criteria and shows how to ask for revisions that preserve what works.