Decide how you'll quit before you start
Most operators know when to start something and almost never decide, in advance, when to stop it. A kill rule — a real metric, a window, and an automatic consequence, written down before launch — is how a small budget keeps flowing toward what's working instead of what you're only hoping for.
Decide how you'll quit before you start
Most small operators know when to start something. Almost none decide, in advance, when to stop it. So the campaign that isn't working keeps running, because pulling it now would mean admitting the money already spent was wasted — and the money already spent is exactly the thing you can't get back no matter what you do next. The fix isn't willpower in the moment. It's a rule you wrote down before the moment arrived: decide how you'll quit before you start.
The sunk cost is the trap, and it's invisible from the inside
Once you've put real effort or real dollars behind something, your judgment about it quietly stops being about the future. It becomes about justifying the past. A week of zero results reads as "give it more time" instead of "this isn't landing," because more time is the only thing that could make the week you already spent feel like it meant something. That's the sunk-cost reflex, and you cannot reason your way out of it in the heat of it — the whole point of the trap is that it feels like patience while it's happening.
You beat it the only way it can be beaten: by making the decision earlier, when you had nothing invested and could think clearly. A kill rule set in advance is a message from the version of you who wasn't emotionally committed yet — and that version is the one you should trust.
What a kill rule actually looks like
It's a concrete, boring, pre-committed threshold that says this route ends here. Ours is a starve rule: if something is spending and produces two straight weeks with zero sales, its budget goes to zero. Not "we'll reassess." Not "let's tweak the copy one more time." To zero. The number was chosen before any campaign launched, precisely so that no single disappointing campaign gets to argue its own case later.
The rule needs three things to work. A metric that isn't a vibe — sales, not impressions or "engagement." A window — long enough to be fair, short enough to matter. And a consequence that's automatic, so triggering it isn't a fresh painful decision every time; it's just the rule doing what you already told it to do.
Killing one thing is how you fund the next thing
A kill rule sounds like it's about loss. It's really about redeployment. Every dollar and every hour still trapped in a route that isn't working is a dollar and an hour not available for the route that might. The operator who cuts the dead campaign fast isn't more ruthless than the one who lets it limp — they're more funded, because they freed the resources to concentrate somewhere with a pulse.
This is the same discipline from the other direction as earning the budget in the first place. You make a product prove organic demand before it gets spend; and you make spend keep proving itself, on a clock, or it loses the budget back. Both gates exist so a small pool of money always flows toward whatever is actually working and away from whatever is only hoping.
The whole rule in one line
Before you start, write down the number that ends it — a real metric, a real window, an automatic consequence. Then when the disappointing week comes, and it will, you're not making a hard call under pressure. You're keeping a promise you made yourself when you could still see straight.
Ready to try PromptGarden?
Grow, organize and share your prompt library
Browse Prompt Garden →Keep reading
A rule you'll waive under pressure isn't a rule, it's a preference
Every operation writes down its rules before it needs them: the threshold that opens spend, the stretch that closes it, the bar a result has to clear before anyone acts on it. Written down, in the calm, they sound obvious. The test is never whether you can write the rule. It's whether you still follow it the one time it tells you something you don't want to hear. A rule that bends the moment it's inconvenient was never a rule — it was a preference wearing a rule's clothes, and preferences change with mood, with how the week is going, with whoever's loudest in the room that day. The whole point of writing the threshold down ahead of time was to take that vote away from your mood. If the number can still move after the fact, you didn't pre commit to anything; you just delayed the negotiation. This is where most operating discipline actually fails, and it isn't usually dramatic. Nobody announces they're abandoning the rule. They just find a reason this instance is different, this signal is noisier than usual, this is the one case that deserves another look before the gate closes. Every exception is reasonable in isolation. The pattern of exceptions is the actual decision, and it's being made by default instead of on purpose. The fix isn't a stricter rule. It's noticing, in real time, the exact feeling of wanting to make one — and treating that feeling as the signal the rule exists to catch, not a reason to set it aside. A gate that only holds when holding is easy isn't protecting the operation from anything. It's just decoration for the times nothing was being tested.
A pricing change you can't undo isn't a test, it's a bet
A price change you can't reverse without a customer noticing already happened the moment you shipped it -- the only thing left to learn is how bad it is.
Design the test that could prove you wrong
Most tests operators run are quietly designed to succeed. The landing page gets compared against a worse version of itself. The email subject line gets an A/B split with a two day window and a sample too small to mean anything either way. The result comes back favorable almost by construction, and the favorable result gets treated as proof rather than as the foregone conclusion it always was. A test that cannot fail isn't a test. It's a ritual that produces the appearance of evidence on demand. The tell is simple: before you run it, ask what result would make you change your mind. If nothing would if a bad number gets explained away as bad luck, wrong timing, or a fluke, while a good number gets banked as proof the test was never actually deciding anything. It was decoration on a decision you'd already made. Designing a test that could prove you wrong means picking the threshold and the sample size before you see the data, the same discipline a spend gate or a kill rule already forces on a budget. It means naming, in advance, the specific outcome that would make you stop, pivot, or admit the assumption was wrong not the outcome you expect, the outcome that would actually change your behavior if it showed up. This is uncomfortable on purpose. A test built to confirm what you already believe is cheap reassurance. A test built with a real chance of embarrassing you is the only kind that tells you anything you didn't already know.
The Loop