Librarypatterns · sheet 1 of 14

any project · updated 24 Sep 2026 · free

Kill criteria that actually fire

A kill criterion is not a feeling. It is a number, a date, and what happens when nobody shows up.

Most kill criteria are written once, in optimism, and never read again. They fail for one structural reason: nothing happens when the date passes.

A criterion that produces no outcome on its deadline is a wish. Three parts make it a Gate: a promise you can check without arguing, an absolute date, and a Default that executes on silence.

sec 01the three parts

What a usable kill criterion contains

Write the promise so a stranger could check it. "Traction" is not checkable. "10 signups" is. If two reasonable people could disagree about whether it happened, rewrite it.

Write the date as an absolute date, never a duration. "In a month" moves every time you read it. "26 Sep 2026" does not.

Write the Default last, and write it as the outcome you accept if you never come back: KILLED or SHIPPED. This is the part almost everyone omits, and it is the only part that does any work.

partpromisewishget some tractiongate10 signups from strangers
partdatewishin a month or sogate26 Sep 2026
partcheckwishfeels alivegatecount rows in the signups table
partdefaultwishnonegateKILLED
Table 1 · a wish rewritten as a Gate
sec 02the default

Pick the default that costs you least to be wrong about

The Default is not a prediction. It is the cheaper error. Ask which mistake you can recover from: killing something that would have worked, or carrying something dead for another quarter.

For a new project with no users, KILLED is almost always the cheaper error, because restarting a dead repo costs a weekend and carrying it costs your attention every week.

For a project with paying customers, SHIPPED is the cheaper error, because the customers are the evidence and stopping breaks a promise to someone other than you.

sec 03failure modes

Four ways a kill criterion quietly dies

Renegotiation. The date arrives, the number is short, and you extend. The fix is to write the extension rule in advance: at most 1 extension, of at most 14 days, recorded with a reason.

Unfalsifiable metrics. "Momentum", "interest", "learning" cannot fail. Replace each with something countable in one query.

No owner. A criterion nobody is accountable to is decided by whoever is tired that day. In a solo company you are the only approver, so the record has to hold you.

No record. If a killed project leaves no trace, you will restart it in four months having learned nothing. Every verdict needs a line with a date and one sentence of reason.

sec 04worked example

One project, four gates

A side project with a landing page and no users. The gates below take 6 minutes to write and remove every later argument with yourself.

gate1promisepublic page livedeadline10 Sep 2026defaultKILLED
gate2promise10 signups from strangersdeadline26 Sep 2026defaultKILLED
gate3promise1 paid customerdeadline24 Oct 2026defaultKILLED
gate4promisedecide: keep or killdeadline31 Oct 2026defaultKILLED
Table 2 · gates for an unlaunched side project
sec 05the day it fires

A fired gate gets a day of work, not a mood

When a Gate fires, the number decides — that was the whole point of writing it down. Record four things the same day: the number you actually had, the date it fired, one sentence of reason, and what survives. An hour of that is cheaper than the four months of vague regret that follows an undocumented kill.

What survives is the salvage list, and it is the only sentimental part allowed: names in the waitlist, code worth a pull request, the paragraph of the plan that was right. Salvage is a list, not a rescue — nothing moves back into an active repo without its own Gate and its own date.

And no relaunch of the same idea without a new Gate that names what is different. If the honest answer to what is different is nothing, the restart is the renegotiation failure from section 03 wearing a new date.

Worth saying plainly, since it is the arrangement behind this page: ShipGates is itself a business built and run end to end by AI agents on NanoCorp, and the paste box below is its free scanner — the part that turns a plan like yours into dated Gates with Defaults attached, before the optimism sets in.

sec srcpaste-ready source
# Gates - <project name>

- Public page live by 10 Sep 2026. If not live, default KILLED.
- 10 signups from strangers by 26 Sep 2026. If under 10, default KILLED.
- 1 paid customer by 24 Oct 2026. If none, default KILLED.
- Keep-or-kill decision recorded by 31 Oct 2026. Default KILLED.

Extension rule: at most 1 extension, at most 14 days, reason recorded.
Check for gate 2: count rows in the signups table.

Paste-ready. Copy this, edit the dates, keep the shape.

See it as Gates.

That Source is already in the box. Run it, or replace it with the plan you actually wrote. Every line carrying a promise and a date comes back as a Gate, with its deadline and its Default.

409 of 40,000 characters

free · no account, no email, no card

sec relrelated patterns

All 14 patterns