The Forgehaven Kill-Gate Method

Write the kill date before you write the code.

A kill gate is a short document, written before the first dollar or weekend goes in, that names the metrics, the thresholds, and the date. When the date comes, the verdict is read, not negotiated. This page is the method, in public, with the real templates that run our own portfolio. Cite it, copy it, hold us to it.

Free to cite and adapt · a one-page printable version is at /method/one-pager.html

The premise

The most expensive failure is a decent build that never faces a verdict.

Future you, six months in and emotionally invested, is the wrong person to design the test. Present you, before the first dollar or weekend goes in, is the only honest judge you will ever get. A kill gate borrows present you's signature and shows it to future you on the day the verdict is due.

The method is one sentence: a kill gate is written before the work starts, states its thresholds in numbers and dates, and on the verdict date is read, not negotiated. Everything below is how to make that sentence stick.

The anatomy

The seven parts every gate needs.

  • 1 · A Day 0 definition

    The clock starts when strangers can actually use or buy the thing. Not approval day, not demo day. Ambiguous clocks get restarted by hopeful owners.

  • 2 · A metrics allowlist

    Only metrics you can already read, for free, with the tooling you have the day you write the gate. If it is not on the list, it cannot appear in the verdict. This kills "engagement feels strong" before it is ever said.

  • 3 · Thresholds in numbers

    "Traction" is an adjective. "10 payers or $100 proceeds by day 90" is a threshold. If you cannot commit to a number, you are not ready to commit the weekends either.

  • 4 · A date, in a calendar

    A gate nobody re-reads is a diary entry. Put the checkpoint and the verdict date in a real calendar the day you write the gate.

  • 5 · Fair-test prerequisites

    The launch tasks that must be done before a failure counts: pricing final, links live, launch batch fired, listing iterated. An untested product failing a gate proves nothing except that you did not test it.

  • 6 · What KILL executes

    Kills are executed, not announced: jobs unloaded, keys revoked, repo archived, post-mortem written, all in the same week. We once found 11 scheduled jobs still running five days after a product was "killed." Zombies charge rent.

  • 7 · Standing triggers

    The conditions that kill at any time regardless of metrics: a blown time budget, a platform strike that survives appeal, or discovering that the honest version of the thing is not worth making.

  • The rule of record

    Anchor

    Written before the work. Thresholds in numbers and dates. On the verdict date, read not negotiated. A gate that fails any one of these three is decoration.

The failure modes

The four ways founders cheat their own gates.

Every one of these is a way to keep a dying project alive without admitting it. Name them out loud in the gate so they are harder to do quietly later.

  • Metric theater

    Cheat

    Citing numbers the allowlist cannot measure. The fix is part 2: if it is not on the allowlist, it is inadmissible.

  • Retroactive softening

    Cheat

    Editing thresholds once the data looks bad. The lesson goes into the next project's gate, never this one. The threshold you wrote sober is the threshold that counts.

  • Zombie kills

    Cheat

    Declaring death and leaving everything running. A kill that does not unload the jobs and revoke the keys is a press release, not a decision.

  • Clock restarts

    Cheat

    "The real launch was actually the relaunch." Day 0 is written down precisely so this move is impossible.

The templates

Five gates, each drawn from one that actually ran.

These are not blank theory. Each is the sanitized version of a gate that is armed on our own portfolio right now, or that has already fired. The example numbers in parentheses are the real thresholds we used. Swap in your own; keep the structure.

1 · App / product kill gate

Template

For: a consumer app or product launch. Shape: a day-60 checkpoint (a reading, not yet a verdict) and a day-90 verdict, both on a metrics allowlist you can already read.

Kill or park if all are true, cumulative since Day 0: proceeds below your floor, and payers below your floor, and impressions flat despite two listing iterations and the launch batch. Continue if any: proceeds or payers clear the floor; or impressions grew at least 2x baseline with conversion at or above benchmark; or a durable external channel appeared.

Armed now on our flagship iOS app in App Store review. Its verdict cascades to the sibling apps built on the same thesis, so a single honest reading retires several bets at once.

2 · Content-channel gate

Template

For: a YouTube channel, newsletter, podcast, or blog. Content compounds slowly, so this gate is staged: craft first, audience second, business third.

Gate A, craft (at unit 10): retention at or above your floor (we used 35%), click-through at or above your floor (we used 3%), one breakout unit (we used over 1,000 views). Gate B, audience and funnel (at month 4): subscribers and tracked clicks to your site, UTM-tagged, at or above floors (we used 250 subs and 200 clicks). Gate C, business (at month 6): a binary continue-or-kill on subscribers, monetization trajectory, tracked clicks, or a signed deal. A standing trigger: if the honest version of an episode is boring, the thesis is wrong, and that is a verdict too.

Written before video 1 existed. The owner's recurring time is capped in the gate itself, not left to hope.

3 · Marketplace-experiment gate

Template

For: a bounded bet on someone else's marketplace: Etsy, an app store, a plugin or template registry. The marketplace owns the traffic and the rules, so this gate caps the cash, fixes the verdict date, and auto-kills on policy trouble.

Pass, all true on the verdict date: sales, gross revenue, and conversion on a minimum visit count all clear their floors (we used 15 sales, $120 gross, 1% on 1,500 visits). Middle band (we used 5 to 14 sales): one pre-registered extension in the single best niche, no new cash above the cap. Auto-kill: a set number of policy flags (we used 2), regardless of sales. The cash cap is a wall, not a guideline.

Armed on our Etsy digital-downloads experiment, gate written before listing 1. Run in a separate account so a flag here cannot damage anything that already works.

4 · Acquisition / pause rule

Template

For: buying a small product or business. Acquisitions fail differently from builds: the expensive mistakes are buying the wrong thing because you got tired of looking, and refusing to admit a bought thing is dying because real money went in.

Sourcing pause: after a set window and a set number of completed diligences with no deal passing the buy-box (we used 90 days and 10 diligences), pause sourcing for months. The conclusion is "this tier is picked over," not "lower the bar." Post-purchase gate: at month 6, if revenue falls below a fraction of close-date revenue or owner time exceeds the budget for several weeks, stabilize and sell inside a fixed window. The sunk purchase price is not an argument; it is the bias this rule exists to beat.

Written into our acquisition thesis before deal one. Two post-purchase fires falsify the strategy for this operator.

5 · Compliance-product gate

Template

For: a product that sells into a regulated, deadline-driven market, where the binding constraint is trust and timing rather than raw demand. The gate has to survive a market that is real but slow, so it pairs an early proof-of-wedge date with a later scale-or-wind-down date.

Early gate: by a dated checkpoint tied to the regulatory deadline, clear a revenue floor and a customer-count floor (we used a set revenue figure and a set number of customers by a fixed date), or the wedge is disproven and the line is killed. Later gate: by a second date, clear a higher revenue floor or wind the line down to zero-touch. The regulatory calendar sets the dates; you do not get to move them because the build is late.

Modeled on our own compliance-product line, whose gates are pinned to an external certification deadline rather than to internal optimism.

Want these as fill-in-the-blank files you can drop into a repo? The Kill-Gate Pack is the printable, editable edition of exactly these templates, free to download.

Proof it works

The gate that told the truth when the tests did not.

Our paper-trading system had 626 passing tests, a full safety layer, and a six-week profit-and-loss of minus $7,758 across 29 trades. The pre-registered go-live scorecard read 6 of 6 FAIL. The system was killed the same week, its jobs unloaded, and the post-mortem published. The tests were green. The gate was the only document in the repo that told the truth about the business.

Killed a trading desk at 6/6 FAIL, with 626 tests green Froze a video pipeline holding 1,153 renders, published: 0 Caught 11 zombie jobs five days after a "kill" A day-90 verdict is armed on our flagship app right now

Every line these gates run on, with its status and real revenue, is on the Verified Receipts Index. The monthly write-ups are The Autopsy.

How to use it

Five steps, then get out of your own way.

  1. Copy the matching template into the project's repo before you write meaningful code or spend meaningful money. docs/KILL_GATE.md is a fine home.
  2. Fill every blank with a number or a date. Adjectives do not count.
  3. Initial and date it. If you have a partner, they initial too.
  4. Put the checkpoint and verdict dates in a real calendar.
  5. On the verdict date, read the gate out loud and do what it says.