Every revenue-path project I start carries a death date. Four weeks from kickoff for the lean version. Six weeks for the version that needs runway. The date is written down before the first commit. If the project has not earned its way past the date when the date arrives, it dies.
This sounds harsh. In practice it is the kindest thing I do for myself.
The expensive lie
The most expensive sentence in solo founding is "I'll just keep working on it on the side." It sounds modest. It sounds responsible. It is neither.
The cost of that sentence is paid in three currencies. The first is calendar time. Projects that should have been killed at week six instead die at week thirty-six, having consumed nine months of weekend energy that could have gone to something with traction. The second is decision quality. Once a project has consumed enough effort, you stop asking whether it should continue and start asking only how to make it work, which is the wrong question. The third is the opportunity cost of all the projects you didn't start because you were busy not killing the one in front of you.
Pre-committing to a death date prices all three costs into the project on day one. You don't ask "should I keep going" every week. You ask once, at the date. Until then you build.
How the timer works
Four-week version, used for projects with a tight feedback loop, usually a service, a piece of content, or a tool that real users can try in under a day. Four weeks is enough time to build a minimum demonstration and put it in front of three to five people. If, at week four, you cannot point to specific people who have used the thing more than once, the project dies.
Six-week version, used for projects with a longer setup curve, usually anything involving onboarding, integrations, or a longer sales conversation. The bar is the same, specific users using the thing more than once, but the runway accounts for the extra setup cost.
The date is in the calendar. Not "around six weeks." A specific date. When the date arrives, the project either has its evidence or it doesn't, and the decision is mechanical.
What "kill" means
Kill is not delete. It is archive, with a written post-mortem. The repo is moved into the archived projects folder. The vault note for the project is updated with a "killed at week N, reason X" entry. The domain, if there is one, is parked or released. The Slack channel is closed.
The post-mortem is one page. It answers three questions:
- What did I believe at the start that turned out to be wrong?
- What did I learn that I want to keep?
- What would have to change for me to revisit this?
The third question is important. Killing a project is not the same as forbidding the idea. Many of my best-running projects today were second or third attempts at killed ideas. The killing taught me what the idea actually needed.
What survives the rule
Revenue-path projects with users surviving past the date, they continue. The rule is not a budget cap. It's a checkpoint. If, at week six, three customers are using the thing and one of them wants to pay, you continue. The rule fired and the project passed.
Open-source projects are exempt. Reputation builds on a different clock. A library that gets five GitHub stars in six weeks is not failing. It's just early. The OSS path has different signals and its own pace.
Personal projects are exempt. If I'm building a tool for my own use, the success criterion is that I use it. There's no kill rule because there's no external validation requirement.
Client work is obviously exempt. A contract ends when the contract says it ends.
The psychology
Most of what makes the kill rule work is psychological, not mechanical. Three pieces.
First, the rule pre-commits the future version of you. Six weeks in, you will not want to kill the project. You will have invested in it, you will have told friends about it, your identity will be slightly attached to it. The version of you who wrote down the death date six weeks ago is more honest than the version sitting in front of the project now. The rule is your past self protecting your future self from your present self.
Second, the rule makes starting cheaper. If every project must work or die in six weeks, you stop treating project starts as huge commitments. You start more things. You learn faster.
Third, and this one took me longest to internalize, the rule lets you say no to ideas without feeling like you said no permanently. "I won't start that this month" is a much smaller no than "I won't ever start that." The ideas folder is real. The depends-on conditions are real. The rule isn't a vow of celibacy from ideas. It's a budget on which ideas get active attention this quarter.
The week-five flinch
There is a predictable bad moment that arrives around week five of a project that is about to fail the rule. You can feel the date coming. You know the evidence isn't there. You start looking for reasons the rule doesn't apply to this particular case. The customers are slow this month, the market timing is unusual, the next version will be the one that lands.
When the flinch arrives, the project is about to die. The flinch is the project dying. Everything you tell yourself after the flinch is rationalization.
The discipline is not to be smarter than the flinch. The discipline is to recognize it when it shows up and let the date land.
What I get for the cost
I kill more projects than I keep. I don't lose sleep about the ones that died. I sleep worse about the ones I should have killed and didn't, the year-long zombie projects that ate weekends and produced no evidence of life.
The rule is not about being decisive. It's about removing the need to be decisive. Once the date is written down, the project either earns its survival or it doesn't, and either outcome is a win. Survival means you have something real, and death means you have your time back and a one-page lesson.
Most weeks the cheapest validation tool I own is a date on the calendar.
The exact tag-and-timer system lives in my project-level instructions file. The file is short. The hard part is honoring it.