The kill criteria: how I decide when a product is dead

Every product I build needs a kill criterion before it launches.

I do not mean a vague intention to reassess if things are not working. I mean a specific rule: if the product is available to buy, I have made a serious attempt to distribute it, and there are no paying customers within three months, the product stops receiving active investment.

No extensions because the next marketing push might change things. No quiet negotiation with myself because I am attached. The rule exists so I do not have to make the decision under the exact conditions that make the decision hardest.

Why pre-commitment matters

The moment to set a kill criterion is before you are attached to the thing.

After three months of building, after the launch, after you have told people about it, written about it, and put your name on it, you are attached. The decision to stop involves ego, sunk cost, and the quiet dread of explaining that something did not work. Those are terrible conditions for clear thinking.

Before you build, the product is still a hypothesis. You can look at it more cleanly. You can decide what evidence would make the hypothesis worth continuing and what evidence would mean the current execution should stop.

That is what pre-commitment gives me: a decision made in low-attachment conditions, designed to execute when attachment is highest.

What three months actually means

Three months post-launch does not mean three months of quietly building something nobody knows exists. That only tells you whether you can build in obscurity.

The clock starts when the product is available to pay for and I have made a deliberate effort to find customers. The product needs to be visible, findable, and positioned clearly enough that the right person understands what they would be paying for and why.

If that genuine effort produces no paying customers in three months, the signal is real. The market may not want what I built, may not want it from me, may not want it at that price, or may not have been reached in a credible enough way to validate the model. Each version tells me something, but none of them justifies carrying the product indefinitely as if signal is about to appear by magic.

When the evidence is clear, stopping is the cost of taking it seriously.

What termination actually looks like

Termination does not automatically mean deleting the code. It means stopping active investment of time, money, attention, and identity into a product that is not producing commercial signal.

The code may stay. The domain may stay on a minimal plan. If users exist, even non-paying users, they do not get abandoned without notice. What stops is the active build work, the marketing push, and the cognitive overhead of carrying the product as if it still deserves the same attention as the products producing signal.

That distinction matters when you build a portfolio as a solo operator. If every product stays alive regardless of evidence, the portfolio becomes a maintenance trap: five projects, each requiring attention, none receiving enough focus to actually work.

The kill criterion is what makes multiple products survivable. It lets the portfolio learn without letting every experiment become a permanent obligation.

The emotional reality

I do not want to pretend this is easy.

Terminating something you built requires honesty about the difference between “needs more time” and “is not going to work in this form.” That distinction is hard from inside the product. The thing you built always has more potential from your perspective than the market is reflecting back. You can see the roadmap, the next version, the cleaner onboarding, the better positioning, and the one feature that might finally make it click.

That is exactly why the rule has to exist.

The question cannot be “do I still believe in the idea?” I will usually still believe in some version of the idea. The better question is what evidence would change the verdict: a paying customer, a qualified inbound inquiry that converts, a usage pattern that shows someone has built the product into their workflow, or a clear distribution signal that makes the next three months materially different from the last three.

If none of that appears, the hypothesis has been falsified. Not the entire idea forever, but this execution, at this price, for this audience, through this distribution path.

Learn from it, stop carrying what is not earning its place, and build the next thing with the evidence intact.

What this means for my products

The discipline applies to everything I build: Gestalt, Protocol, Neon Oracle, and whatever comes next. Some are live, some are still moving toward the next serious release, and each has to earn continued attention through signal rather than affection.

That is the point. The things I care about most are the ones most likely to distort my judgment, so they are also the ones that need the rule most.