For eight months, I maintained a digital course that generated EUR 200-300 per month. The course required monthly content updates, customer support, and technical fixes. Total monthly time: about six hours. My effective hourly rate on the course was EUR 33-50 — roughly a third of what my consulting generated.
I kept it alive because killing it felt like admitting failure. Every month I told myself “it just needs more marketing” or “I’ll improve it next quarter.” Eight months of this slow drain before I finally pulled the plug.
When I killed it, the six hours per month went to consulting that generated five to ten times the revenue. The course wasn’t sustaining my business. It was draining it like a slow leak in a tire.
Most founders have at least one project like this. A product that isn’t quite failing but isn’t quite succeeding. A partnership that produces just enough to justify not ending it. These “zombie projects” are dangerous precisely because they’re not bad enough to force a decision but not good enough to justify the investment. The Kill or Commit framework forces that decision.
Why Zombie Projects Are So Dangerous
Zombie projects persist in a psychological gray zone. They’re not clearly failing (so killing them triggers loss aversion), and they’re not clearly succeeding (so committing triggers opportunity cost anxiety). The result: they receive just enough attention to survive but not enough to thrive.
This middle path is the worst option. It consumes resources without meaningful returns and prevents those resources from going to something better. In our accelerator program, I’ve watched startups keep zombie features, products, and partnerships alive for months. The pattern: 15-20% of the founder’s attention, 5-10% of results, and energy drained from the core business.
Kill or Commit eliminates the middle. Every struggling project gets one of two verdicts: kill it entirely or commit to it with significantly more resources. The half-alive state is explicitly forbidden.
The Seven-Question Assessment
For each struggling project, answer these honestly. The framework only works with honest inputs.
- Revenue reality: What actual revenue has this generated in the last 90 days? EUR ____.
- Trend direction: Growing, Flat, or Declining compared to the previous 90 days?
- Resource cost: How many hours per week, including thinking about it? ____ hours.
- Opportunity cost: If those hours went to your best activity, what additional revenue would they generate? EUR ____ per month.
- Excitement level: How excited are you about this right now (not when you started)? ____/10.
- Unique advantage: Do you have something objectively superior to alternatives? Yes / No / Unsure.
- 90-day potential: If you doubled your investment for 90 days, would it reach a meaningful milestone? Yes / No / Unsure.
Scoring: Each question can produce a Kill signal:
- Q1-2: Revenue below threshold AND flat or declining → Kill signal
- Q3-4: Opportunity cost exceeds revenue by 2x+ → Kill signal
- Q5: Below 4/10 excitement → Kill signal
- Q6: “No” advantage → Kill signal
- Q7: “No” or “Unsure” potential → Kill signal
Decision: Three or more Kill signals → Kill. Two or fewer → Commit (with conditions).
This scoring prevents emotional override. Your attachment gets one vote (Q5). The other six are data-driven.
Execution: Kill Path
If the verdict is Kill:
- Stop all work within 48 hours (not gradually — fully)
- Communicate to stakeholders
- Archive all materials (don’t delete)
- Reallocate resources to your top performer
- Set a 30-day reminder to verify you haven’t quietly resumed (this happens surprisingly often)
The speed matters. A gradual wind-down becomes indefinite life support. Kill means kill. The Subtraction Audit is the comprehensive version of this thinking — Kill or Commit is the fast version for individual projects.
Execution: Commit Path
If the verdict is Commit:
- Define three specific milestones for the next 90 days
- Increase resource allocation by at least 50%
- Schedule a 90-day Kill or Commit review
- If milestones aren’t met at the review, the project auto-kills
This conditional commitment prevents indefinite life support. You’re not committing forever. You’re committing for 90 days with clear success criteria. If increased investment doesn’t produce results, the project dies automatically.
Three Real Examples
Example 1: Newsletter product (Killed) Revenue: EUR 450/90 days. Flat. 4 hours/week. Opportunity cost: EUR 3,600/month. Excitement: 3/10. No advantage. Unsure potential. Five Kill signals. Decision: Kill. First month of redirected time exceeded the newsletter’s entire 90-day revenue.
Example 2: Workshop format (Committed) Revenue: EUR 3,200/90 days. Growing. 6 hours/week. Excitement: 7/10. Yes advantage. Yes potential. One Kill signal. Decision: Commit. Met all three milestones. Became a core offering.
Example 3: Content partnership (Killed after Commit) Revenue: EUR 800/90 days. Flat. 3 hours/week. Excitement: 5/10. Unsure advantage. Yes potential. Two Kill signals (borderline). Decision: Commit for 90 days. Milestones: 5 leads, EUR 2,000 revenue. Result: 2 leads, EUR 1,100. Auto-kill at review.
Example three shows the system working perfectly. Ambiguous assessment → fair chance with investment → milestones not met → clean kill. No agonizing.
When to Run the Framework
Quarterly: Review every project older than six months that hasn’t met original goals.
When overwhelmed: Kill or Commit is the fastest way to free resources. Killing two zombie projects can recover 10+ hours per week.
Before starting new projects: The resources for your new idea often come from killing a zombie, not from working more hours.
When performance suddenly changes: Revenue drops, engagement declines, key partner leaves — run the assessment immediately rather than hoping for self-correction.
The velocity principle works better with fewer things. Every zombie is drag on your speed. Killing zombies produces immediate velocity gains.
The Emotional Reality
Killing a project you’ve invested in triggers loss aversion, sunk cost fallacy, and a sense of failure. These are real emotions. The framework handles them by separating the decision (data-driven scoring) from the feelings (which you process afterward).
When I killed that digital course, I felt genuine loss. I’d built it carefully. Students had learned from it. But reframing “killing a project” as “graduating from a project” helped. I learned what I needed. Now I was moving to the next thing. The project served its purpose, even if the purpose wasn’t what I originally intended.
The work wasn’t wasted. The lessons went into everything I built next. At Vulpine Creations, some of our best products came from ideas that failed first. Kill the project, keep the learning.
Building a Kill-Friendly Culture
If you work with others — even just one contractor or partner — creating a culture where killing projects is normalized rather than stigmatized matters enormously. At Vulpine, Adam and I had an explicit agreement: either of us could call a Kill or Commit review on any project at any time, and neither of us would take it personally. This agreement removed the interpersonal friction that often keeps zombie projects alive in partnerships and teams.
The language matters too. “Kill” sounds violent but it’s clear. Don’t soften it to “pause” or “put on hold” — these create ambiguity and usually mean the project lingers indefinitely. “We’re killing this project and reallocating resources to [specific alternative]” is clear, definitive, and forward-looking.
The result of a kill-friendly culture: faster decisions, fewer zombies, more resources concentrated on the things that actually work. Every project that gets killed frees energy for a project that deserves to live.
Key takeaways:
- Answer the seven assessment questions honestly — especially opportunity cost, which most founders undercount by 30-50%.
- Three or more Kill signals means Kill — the scoring prevents emotional attachment from overriding data.
- Kill means fully stop within 48 hours, not gradually wind down — gradual wind-downs become indefinite life support.
- Commit means 90 days with three specific milestones and 50%+ more resources — if milestones aren’t met, auto-kill.
- Run the framework quarterly on all projects over six months old, and immediately whenever you feel spread too thin.
