Framework Definition

Kill Switch Protocol

Coined by Richard Ewing, AI Economist

Definition

The Kill Switch Protocol is a structured framework for identifying and deprecating "Zombie Features" — code that requires ongoing maintenance but generates zero incremental business value. Most software organizations have a dangerous bias: they add features but never remove them. Product teams celebrate launches. Nobody celebrates deletions. Over time, this creates what Richard Ewing calls "feature gravity" — a constantly growing codebase where 40-60% of the code serves no active users and generates no measurable revenue, yet still consumes engineering maintenance hours. Zombie features come in several varieties: - **Ghost Features**: features that were built, launched, and never adopted. They sit in the codebase, requiring maintenance, but have near-zero usage. - **Legacy Bridges**: compatibility layers, deprecated API versions, and backward-compatible code paths that serve a tiny percentage of users but add complexity to every future change. - **Vanity Features**: features built because a senior stakeholder wanted them, not because users needed them. Often protected by organizational politics rather than business merit. - **Abandoned Experiments**: A/B test variants that were never cleaned up, prototypes that became permanent, and "temporary" solutions that became load-bearing. The Kill Switch Protocol provides a systematic approach to identification, evaluation, and deprecation: 1. **Identify**: Flag features with less than 5% of peak usage, zero revenue attribution, or maintenance cost exceeding 10% of the feature's value contribution. 2. **Quantify**: Calculate the total cost of keeping each zombie alive (maintenance hours × fully-loaded engineer cost × opportunity cost multiplier). 3. **Assess Risk**: Evaluate deprecation risk — what breaks if this feature is removed? What customers are affected? 4. **Sunset Timeline**: Create a communication plan and graduated deprecation (warning → deprecation notice → feature flag → removal). 5. **Execute**: Remove the code with rollback capability. Monitor for unexpected breakage. The typical Kill Switch audit reveals that 30-50% of maintenance burden comes from zombie features. Removing them frees up 15-25% of engineering capacity for actual innovation.

Why It Matters

Every feature you keep makes every future feature harder. The Kill Switch Protocol provides the organizational discipline to subtract — which is harder politically than adding but often creates more value. For product leaders, the Kill Switch Protocol is the economic argument for saying "no" to feature preservation. When you can show that keeping a feature costs $180K/year in maintenance and generates $0 in attributable revenue, the kill decision becomes obvious. For engineering leaders, the Kill Switch Protocol frees up capacity trapped in maintenance. A team that reclaims 20% of its capacity from zombie features effectively gets 20% more engineering headcount without any new hires. For CFOs and boards, zombie features represent pure waste — capital spent maintaining things that don't generate value. The Kill Switch Protocol turns that waste into available capacity.

How to Calculate

1Inventory all features and map to usage metrics (DAU, MAU, revenue attribution)
2Flag features below 5% of peak usage or $0 revenue attribution
3Calculate maintenance cost per feature: maintenance hours × fully-loaded engineer cost
4Calculate opportunity cost: what else could those engineers build?
5Rank zombies by maintenance cost (highest cost = kill first)
6Execute sunset protocol: communicate → deprecate → remove → monitor