The hardest decision I help founders make is not what to build. It is what to stop building. There is a project on almost every team I review that everyone privately knows is not going to work, and that nobody will kill, because too much has already gone into it. Four months of engineering, a roadmap promise, a founder's pride. So it limps forward, eating the one resource a startup cannot refill: time.
The instinct to finish what you started is usually a virtue. In this one situation it is a trap with a name.
Why smart founders keep funding dead projects
The sunk cost fallacy is the reluctance to abandon something because of what you have already put into it, even when walking away would clearly be better from here forward. It is not stupidity. It is a deeply human response, and it gets worse the more you have invested, which is exactly backwards from how the decision should work.
The money and months already spent are gone either way. They are not a reason to continue; they are a reason to feel bad, and those are different things. The only question that matters is forward-looking: given where we are today, is finishing this the best use of the next three months, or is something else?
Failed software projects are not a rounding error. Estimates put the drag of failed IT projects on the wider economy in the tens of billions of dollars a year. At startup scale, one dead project that nobody kills can be the difference between reaching your next milestone and not.
The tells that you are in it
A few signals show up again and again:
- The pitch for continuing is about what you have already spent, not what you will get. "We are 80 percent done" is a sunk-cost sentence, and that last 20 percent has been 80 percent done for two months.
- The completion date keeps sliding by roughly the amount of time that has passed since you last checked.
- The team has gone quiet. Engineers can usually see a doomed project before founders can, and their silence is data.
- Nobody can crisply state what success looks like anymore, only that stopping would waste the work so far.
How to decide to walk away
Killing a project on a gut feeling is hard and feels arbitrary, so founders avoid it. The fix is to make the decision less personal by setting the rules before you are emotionally underwater.
Set exit points at the start
The cleanest tool I know is to define, when a project begins, the conditions under which you will stop it. For example: we stop if it goes more than 10 percent over the time budget, or if it misses a specific milestone, or if the core assumption it rests on turns out to be false. Written down in advance, these exit points let you be objective later, because you are honoring a decision your calmer, earlier self made rather than passing judgment on the team in the moment.
This is also what makes the kill defensible to everyone involved. "We hit the exit condition we agreed on" lands very differently than "I changed my mind."
Ask the from-here question out loud
When you suspect you are in a sunk-cost spiral, put the real question on the table: if we were starting today, with no code written and no time spent, would we choose to build this now? If the honest answer is no, you have your answer. The existing code does not change it. If a rewrite or a bought alternative would clearly save time and money from this point forward, that is the move, regardless of how much sits in the old approach.
Separate the decision from the blame
Founders stall on kills partly because stopping feels like admitting failure, theirs or the team's. It is not. A project that taught you an assumption was wrong did its job. The failure is not stopping a doomed project; it is continuing one after you knew. Framing the kill as new information acted on, rather than a person who messed up, is what lets a team actually pull the trigger.
The other edge of the knife
I want to be careful here, because "just kill it" is also how founders talk themselves into never finishing anything hard. Not every struggling project is a sunk-cost trap. Some things are supposed to be hard and slow, and abandoning them at the first friction is its own expensive habit, the one behind the second product built before the first one worked.
The distinction is the from-here test. Kill it when continuing is worse than stopping, judged only on the future. Push through when the thing is hard but still the best forward bet and you are just uncomfortable. The sunk-cost trap is continuing because of the past. Grit is continuing because of the future. Same behavior, opposite reasons, and telling them apart is the actual job.
Abandoning a build is a close cousin to two other calls I write about often: killing a live feature you should stop maintaining, and the rewrite-or-refactor decision where the sunk cost of the existing system quietly biases you toward keeping something you should replace. All three come down to ignoring what you spent and pricing only what comes next.
FAQ
How do I tell a sunk-cost trap from a project that is just hard?
Apply the from-here test. Ignore everything already spent and ask whether, starting fresh today, this is the best use of the next few months. If yes, it is hard but worth it. If no, it is a sunk-cost trap and the prior investment is the only thing keeping it alive.
Isn't killing a project a waste of the money already spent?
The money is already spent whether you continue or not. It is gone either way, so it cannot be wasted by stopping; it can only be wasted further by continuing to pour time after it. The waste is future time spent on something you have concluded will not pay off.
How do I kill a project without wrecking team morale?
Frame it as acting on new information, not assigning blame, and lean on exit conditions agreed in advance if you set them. Teams usually feel relief, not defeat, when a doomed project ends, because they saw it coming. What wrecks morale is being forced to keep working on something everyone knows is dead.
What if I am not sure whether to kill it?
Get an outside read from someone with no emotional stake in the code. That is often exactly why founders bring me in on a specific build. If you want a neutral from-here assessment before you decide, you can book a call and we can pressure-test the project against what it would actually take to finish versus what stopping would free up.