Kill Criteria: The One Sentence That Should Exist Before Every Side Project Starts

Draft only. Publishing = CEO approval (public content). Fourth SEO asset (idea #4 of 5 in ssk-gtm.md §7.7,

previously keyword-only). Narrower angle than SSK-SEO-001/002/003 (constitution, approval gates, budget envelopes):

those are about control while a project runs; this one is about deciding when it stops running — the piece

founders skip because writing it feels like betting against yourself. Value-first, product mention only in the

closing paragraph.

Kill criteria: the one sentence that should exist before every side project starts

Most side projects don't die from a bad decision. They die from no decision — a slow fade where the founder never quite says "this isn't working," just quietly stops opening the folder. If you're running one project that's forgivable. If you're running several at once, or letting an agent run parts of one for you, "quietly stop opening the folder" isn't a strategy an agent can execute. It needs a sentence it can check against, not a feeling it can't have.

Here's the pattern that's worked for me.

1. Write the kill criteria before the first line of code, not after the first bad week

The only time you can write an honest kill criterion is before you have a sunk cost to defend. A week before launch, "kill if zero paying customers by day 30" is a plan. A month after launch, the same sentence competing against three weeks of your own work is a negotiation you'll lose to yourself every time. Write it when the project is still an idea.

2. It has to be a number and a date, not a vibe

"Give it some time and see how it feels" is not a kill criterion — it's a way to extend a project indefinitely without ever admitting that's what you're doing. "0 sales by a fixed date" or "fewer than N signups by week 4" is a criterion, because it resolves to yes/no without your mood as an input. If you can't write it as a number and a date, you haven't actually decided what would change your mind — you've decided nothing will.

3. Scale criteria matter as much as kill criteria

The inverse trap is just as common: a project quietly clears every bar you set and you never notice, because you only wrote down the failure condition. Pair every kill line with a scale line — what result means do more of this, not just what result means stop. Otherwise a working project idles at "fine" forever instead of getting the attention a working project earns.

4. The criteria live in a file an agent (or a future, tired version of you) can actually check

A kill criterion that lives in your head gets re-litigated every time it's inconvenient. One written in a file — read at the start of every session, checked against real data (sales dashboard, analytics, a ledger), not vibes — can't quietly drift. This is the same mechanic as a budget envelope: the point isn't the number, it's that the number is written down before the moment it needs to be enforced, so enforcing it later is a lookup, not an argument.

5. When the date arrives, the criterion executes — it doesn't reopen for debate

The hardest discipline isn't writing the sentence, it's honoring it when the date actually shows up and the project has some traction, just not enough. "It's not zero, it's just slow" is exactly the ambiguity the criterion was written to remove. If the number wasn't met, the decision was already made — weeks ago, by a version of you with no sunk cost to protect. The only legitimate move at that point is to write a new hypothesis and a new criterion, explicitly, not to quietly push the date.

---

The point

A side project without kill criteria doesn't stay alive longer — it just dies slower, and takes longer to notice. The fix isn't more discipline in the moment; it's moving the hard decision to a moment before you have anything to lose by making it, then writing it down where checking it is a fact-lookup instead of a feeling. That's one sentence, written early, not a personality trait.

I write this exact sentence — a number, a date, no vibes — for every project before it starts, alongside the constitution and approval-gate files, as part of the [Founder OS Kit]. If you're about to start (or already quietly not-quite-killing) a side project, the criterion is the cheapest insurance you'll ever write, and it only works if you write it before you need it.

asset ideas

• Screenshot: a real (sanitized) kill/scale line pair from a project file — the exact "0 sales by [date] → kill" format.
• Diagram: sunk-cost curve vs. decision-quality curve, crossing at "week 0" — the only point where the criterion is honest.
• Internal-link to SSK-SEO-003 (budget envelopes) — same "write the boundary before you need it" thesis, applied to time/scope instead of money.