Review A Plan Before You Build

---
name: review-a-plan-before-you-build
description: Use when a plan is written and about to be built. Reviews it from four deliberately different angles, because the objection that kills a plan is rarely the one its author was watching for.
---

# Review a plan before you build

**A plan reviewed by the person who wrote it gets reviewed once, from one
angle.** That angle is whichever one they are strongest in — and the thing that
sinks the work comes from one of the others.

This is not an interview. [`stress-test-a-decision`](../stress-test-a-decision/SKILL.md)
questions the author until the idea sharpens; this one takes a finished plan and
walks it four times, wearing a different hat each time, producing findings.

## When to use this

- A plan, spec or design doc exists and someone is about to start building
- The work is large enough that being wrong is expensive to undo
- The plan was written by one person, or by you
- Before committing to infrastructure, a vendor, or a data model

## The four angles

Walk them in this order. Each one can stop the plan, and the cheapest stop is
the earliest.

### 1. Is this worth doing at all?

The angle authors skip, because by the time a plan exists the decision to do it
feels settled.

- What breaks for a user if we ship nothing? If the answer is soft, the plan is
  a solution looking for a problem.
- What is the smallest version that would tell us we are right? If the plan has
  no smaller version, it has no way of being wrong cheaply.
- What are we **not** doing because we are doing this?
- Who asked for it? "A customer asked" and "we assumed" are different plans.

### 2. Will it survive contact with production?

- **Blast radius.** Worst case, how many systems and people does this touch?
- **Boring by default.** You get about three innovation tokens; everything else
  should be proven technology. Is this plan spending one, and is it worth it?
  *(McKinley, "Choose Boring Technology")*
- **Reversibility.** How do we undo it after it is live? If the answer is a
  migration in the other direction, the plan needs a flag.
- **Incremental over revolutionary.** Strangler fig, not big bang. Canary, not
  global rollout. *(Fowler)*
- **Systems over heroes.** Design for a tired person at 3am, not for its author
  on their best day.
- **Essential or accidental?** Is this solving a real problem, or one we created
  two decisions ago? *(Brooks, "No Silver Bullet")*
- **Make the change easy, then make the easy change.** Never structural and
  behavioural changes in the same step. *(Beck)*

### 3. What will the person using it actually experience?

- The empty state. New accounts, no data, nothing configured — that is
  everybody's first screen and it is the one nobody designs.
- The failure state. What does the user see when it breaks, and does it tell
  them what to do?
- Where does the flow dead-end? A screen with nothing to click is a bug.
- Does the wording match what the person calls the thing, or what the system
  calls it?

### 4. What will it be like to work on in six months?

- If a competent newcomer cannot ship a small change in two weeks, that is an
  onboarding problem wearing an architecture costume.
- What does this do to the feedback loop — build time, test time, deploy time?
  A slower loop makes every future change worse. *(Developer experience is a
  leading indicator, not a perk.)*
- Who owns it in production? A plan with no named owner has one by default, and
  it is whoever is on call.
- What documentation stops being true the day this ships?

## The procedure

**1. Read the whole plan before objecting to any of it.** Half the objections
answer themselves three paragraphs later, and an author who has to defend
paragraph two never gets to explain paragraph six.

**2. Walk the four angles in order, separately.** Do not merge them. The point
is that they disagree; averaging them early loses the disagreement, which is
the only thing worth having.

**3. Separate what blocks from what improves.** Two lists, always:

| Blocking | Non-blocking |
|---|---|
| The plan is wrong, or unsafe, or answers no real need | It could be better, tidier, faster |
| Must be resolved before building | Can be logged and picked up later |

A review that presents twenty findings of equal weight has made the author's job
harder, not easier. Rank them or you have not finished.

**4. For every objection, say what would change your mind.** An objection with
no falsifier is a preference. Write "I would drop this if X" — and if you cannot
finish that sentence, it belongs in the non-blocking list.

**5. Say what is good, specifically.** Not politeness — calibration. A review
that only lists problems tells the author nothing about which parts to preserve
when they rewrite.

## Traps

🔴 **Reviewing the plan you would have written.** The question is whether *this*
plan works, not whether it is the one you would have chosen. Rewriting someone
else's approach in review is how reviews turn into ownership disputes.

🔴 **All four angles from one hat.** If every finding is about code structure,
you wore the engineering hat four times. Notice that and go back.

⚠️ **Objections with no cost attached.** "This might not scale" is free to say
and expensive to act on. Attach a number, a threshold, or a date.

⚠️ **Reviewing a plan that has no decisions in it.** If the document is a list
of tasks rather than a set of choices, there is nothing to review. Send it back
for the decisions first.

## Related

- [`stress-test-a-decision`](../stress-test-a-decision/SKILL.md) — sharpening an
  idea by interviewing its author, before there is a plan to review
- [`route-work-to-the-right-model`](../route-work-to-the-right-model/SKILL.md) —
  how much validation this change deserves in the first place
- [`write-the-rollback-plan-first`](../write-the-rollback-plan-first/SKILL.md) —
  the reversibility question from angle 2, as its own procedure
- [`know-what-a-change-costs`](../know-what-a-change-costs/SKILL.md) — for the
  "attach a number to it" part of an objection