When to Kill a Failing Project (And When to Double Down)

Every technology leader faces this decision eventually: you've invested months and significant budget into a project that's clearly not delivering. The team is demoralized, deadlines have been missed three times, and stakeholders are asking uncomfortable questions. Do you kill it or keep going?

The Sunk Cost Fallacy in Software

The most common mistake I see is letting sunk costs drive the decision. "We've already spent $500K, we can't stop now" is a terrible reason to continue. The money is gone regardless. The real question is: what does the future look like?

Red Flags That Signal "Kill It"

The requirements keep changing fundamentally. Not refinement—fundamental pivots every two weeks. This indicates the business problem isn't well understood yet. Stop building until it is.

The codebase has become unmaintainable in under six months. If your team is already afraid to touch the code and you're not even in production, the foundation is rotten. No amount of refactoring will fix architectural rot.

The team has turned over twice. When you're on your third set of developers and still not done, the institutional knowledge is gone. You're essentially starting over anyway.

The original architect has left and nobody understands the design. This is common with over-engineered solutions. If the only person who understood it is gone, you're flying blind.

Green Flags That Signal "Double Down"

The core technology is sound, but execution was poor. Maybe the previous team made bad choices in frameworks or patterns, but the underlying architecture is salvageable. This is actually a good position—you know what not to do.

You have 70% of the functionality working. The hard problems are solved, but fit and finish is lacking. This is absolutely savable with the right attention.

The business case is still valid. Market conditions haven't changed, the ROI is still there, and users are still waiting for this. The fundamentals are sound.

New leadership brings clarity. Sometimes a project fails because of organizational issues, not technical ones. A new CTO or development director can turn things around if the technology is viable.

The Hybrid Approach: Selective Salvage

Here's what most people miss: you don't have to choose between "keep everything" and "burn it all down." The best path is often selective salvage:

• Keep: Database schema, business logic, core algorithms
• Rebuild: UI layer, API surface, deployment infrastructure
• Rethink: Authentication, integrations, background jobs

This gives you the benefit of preserving what works while fixing what doesn't. It's faster than a full rewrite and cleaner than trying to polish a broken codebase.

The Decision Framework

Ask these three questions:

1. Can we ship something valuable in the next 90 days? If not, something is fundamentally wrong.

2. Do we have the right team to finish this? Not the team we wish we had—the team we actually have.

3. Is the business still waiting for this? If stakeholders have moved on or found workarounds, you're building something nobody wants.

If you answer "no" to two or more, it's time to consider killing it.

What Happens After You Kill It

The organization will survive. Actually, they'll likely be relieved—everyone knew it wasn't working but nobody wanted to say it. The budget can be reallocated to something with better odds.

But if you decide to push forward, commit fully. Half-hearted efforts just extend the pain. Bring in outside help if needed, give the project real priority, and set honest deadlines.

The worst outcome is the zombie project that limps along for years, consuming resources and providing nothing. Make the hard call either way.

Related Posts

• 5 Signs Your .NET Project Needs Rescue
• Why Software Projects Fail in the First 90 Days
• The Hidden Cost of 'We'll Just Rewrite It'