This is the last gate before real application code exists. Everything upstream — brief, brandbook, mockup, spec, competitive analysis — is now "done." This lesson is the pass that asks whether "done" is true and whether "build" is right. Skim the pre-mortem and the go/no-go block if nothing else.
TL;DR
There is a moment right before the first line of real app code where a project is maximally decided and minimally sunk. Every document exists; almost no money is spent. This is the single highest-leverage review in the whole process, and most teams skip it because all the documents look finished and momentum wants to write code.
Don't skip it. Run a formal gate with five moves: (1) a pre-mortem — assume it's dead in 12 months and write the most likely cause now; (2) kill criteria decided in advance, in cold blood, before sunk cost exists; (3) a confidence audit — which brief claims are still [A]/[?] instead of [V], and is that acceptable to build on; (4) a document-coherence check — did the mockup's screens actually resolve into the spec's data model, or did a tension get quietly buried; and (5) a named go/no-go — one paragraph of what you're building and for whom, plus a person and a date, not an implicit "well, I guess we're building it now."
This is the brief's "pros/cons" table and its separate "completeness audit" (see How to Write a Brief), zoomed out from a single document to the whole concept — every document reviewed together.
Why this gate exists
The rule this lesson formalizes, stated plainly: nothing enters the real-coding phase without a closed set — one paragraph on what/for-whom/why-it-sells, financial milestones, a roadmap, an approved visual identity, and approved mockups. [V, from real process history] "Closed," not "mostly there." The gate's only job is to check that this set is genuinely closed and genuinely coherent, and then to make a real decision on the record.
Cost is the entire argument. Fixing a fatal flaw here costs an editing session. Fixing it after three months of code costs three months of code. The mockup lesson already sold you on absorbing surprises cheaply before real code — this is the same trade applied to the concept itself, one level up.
Move 1 — The pre-mortem
A post-mortem asks "why did it die?" after it's dead and you can't act. A pre-mortem asks the same question now, while the answer is still free to fix.
The prompt is exact, and you must actually write the answer, not think it:
"It is 12 months from today. This project has clearly failed. Write the single most likely reason why."
Write it in the project's own past tense, first person, as if it already happened. The specificity is the point — "marketing was hard" is a non-answer; "we never solved cold-start, so early users opened an empty neighborhood feed and churned in week one" is a finding you can pre-empt.
Pre-mortem, Blockyard (running example). "It died because we shipped verified-neighbor trust and household accounts flawlessly, and none of it mattered, because at launch every neighborhood was empty. A verified badge on a feed with four listings is still a feed with four listings. We built the retention machine before we built the reason to show up, ran out of runway seeding metros one at a time, and the funnel math we wrote in the competitive analysis quietly assumed density we never reached." [A]
Now the pre-mortem becomes work: the most likely death is cold-start density, not feature completeness. That reorders the roadmap before a line of code — seeding and density have to precede the household-accounts polish, even though the spec makes household accounts look like the fun part. A pre-mortem that doesn't change your plan wasn't honest.
Write two or three. The first is usually the obvious one; the second is often the real one.
Move 2 — Kill criteria, decided cold
Sunk cost corrupts judgment predictably. Six months in, with code written and identity attached, you will rationalize any warning sign. The defense is to decide the walk-away thresholds now, in writing, while you have nothing invested and can still think clearly.