The six-step pre-build process is unevenly weighted. Steps 1, 4, and 6 are useful but cheap — research is hours, the CLAUDE.md drop is a copy-paste, the pre-mortem is an hour. The whitepaper is where the actual cost lives, and it’s also where the project is decided. The other five steps either feed it, refine it, or stress-test it. None of them replace it.
Most projects I’ve seen skip the whitepaper or write it too gently. The result is the same: a document that reads as plausible but isn’t binding. When the implementation hits an ambiguity, the whitepaper either doesn’t address it or addresses it in a way that supports both available interpretations. The team picks one, the build proceeds, and three weeks later someone asks “wait, was that what we agreed?” and the whitepaper says yes to whatever you wanted it to say.
A useful whitepaper has the opposite property. It’s specific enough that an honest reader can’t claim it supports their preferred interpretation when it doesn’t. It binds.
What the document is for
The whitepaper isn’t documentation. It’s not a roadmap. It’s not a pitch deck.
It’s a contract between me and the project, written before any code, that locks down what’s being built, what isn’t, what success looks like, and what failure looks like. The contract gets dropped into the project folder so every subsequent agent invocation reads it as load-bearing context. Mid-build, when the implementing agent or I am about to make a decision that contradicts the brief, the brief wins. That’s the whole point.
Three properties make a whitepaper a contract rather than a wishlist:
- It can be read once and answer the major questions. A reader who never sees the codebase should know what’s being built, who it’s for, and what makes it succeed or fail.
- It says no out loud. Anti-requirements (“must not do X”), out-of-scope sections (“not in this build”), and explicit failure criteria are non-negotiable. They’re the part of the document that’s actually doing work.
- It survives the third reading. I draft, refine, sleep on it, refine again, sleep on it again, and read once more. If the third reading produces edits, it’s not done.
What the document needs to contain
Ten sections. Plain language. One paragraph each, sometimes less.
The first three define the project. What this is — one paragraph that, on its own, tells a stranger what’s being built and why. Who it’s for — one user persona. Not a market segment, not a buyer profile, one person who operates this system day to day. What it must do — a numbered list of functional requirements, each one testable. If you can’t write a one-line acceptance check for a requirement, it isn’t a requirement, it’s a wish.
The next two define the boundary. What it must not do — anti-requirements, the things you’ve explicitly chosen not to build. Each one closes a future scope-creep loop before it opens. What’s in scope / out of scope — the line that decides what arguments you’ll have later. Both lists in writing. The out-of-scope list is the more important of the two, because it’s what prevents the project from quietly absorbing every adjacent idea over the next quarter.
The next two define correctness. Success — in numbers, with thresholds. Numbers, not adjectives. If you can’t put a number on it, you can’t tell whether you’ve shipped it. Failure — in numbers, also with thresholds. Defining failure ahead of time is the only way you’ll recognise it later, when optimism around the build is at its highest. The most common omission across whitepapers I’ve seen is missing failure criteria. Without them, projects don’t end — they degrade indefinitely while the operator hopes they’ll come back.
The last three are the pragmatic bits. Dependencies with failure mode for each. If any external system goes down, you should already know what your system does in response. Open questions that need to be closed before the brief locks. Lock criteria — the conditions under which the document is finalised, the third reading produces no edits, and the build can begin.
The most common ways a whitepaper fails
I’ve written whitepapers that didn’t bind. The pattern of failure is predictable.
Vague success criteria. “The system works reliably.” That’s not a criterion, that’s a hope. Useful: “Hard-bounce rate ≤ 1% over rolling 30-day window. Daily send volume ≥ 250 on every weekday for 4 weeks straight.”
Missing failure criteria. Almost everyone defines what good looks like. Almost no-one defines what bad looks like. Without an explicit failure threshold written down before the build, you’ll defend the project after it crosses the threshold. The threshold has to exist before the result does.
Sloppy out-of-scope. A blank out-of-scope section means you’ll re-litigate every adjacent feature mid-build. A useful out-of-scope list is specific: “No reply auto-classifier in this build. Replies are read by a human until reply volume justifies otherwise.” Now the question is closed.
No dependency failure modes. “Uses Postgres” is a dependency name, not a dependency analysis. The whitepaper should answer: what happens to the system if Postgres becomes unavailable for four hours during business hours? If the answer is “I don’t know,” the brief isn’t done.
Multiple personas. The “who it’s for” section has more than one user, with different needs. The build now has to serve both, and serves neither well. Pick one. Note the other as out of scope.
Why the third reading rule works
The first draft of a whitepaper captures what you’ve thought about. The second pass catches the contradictions. The third pass — usually a day later, with sleep in between — catches the things that read fine when you wrote them but read worse when you encounter them as a reader rather than as the writer.
When the third reading produces no edits, it usually means you’ve internalised the brief well enough that you can no longer see what’s missing from it. That’s the moment to lock it and hand it to the next stress-test phase, the what-if audit and the pre-mortem, which exist precisely to catch what you can no longer see.
What I learned from skipping it
The outbound campaign I rebuilt from a no-code stack didn’t get a proper whitepaper at the start. I migrated under deadline pressure and skipped the contract step, treating the no-code system itself as the spec. Half of the eight production incidents documented in that case study would have been caught by a whitepaper that took the failure-criteria section seriously. The other half required running the system to surface, but the failure-criteria section would still have made each one cheaper to recognise once it happened.
I now write the whitepaper even when it feels excessive for the size of the project. The cost of writing it for a small project is an hour. The cost of skipping it for a project that turns out to be larger than expected is whatever the rebuild costs. I’ve paid the second cost. Once is enough.