When to Kill a Failing Project: Stop Wasting Time on Bad Hires

• The "One More Week" Delusion
• The Poison of the Sunk Cost Fallacy
• The Micro-Win: The "Three Strikes" Termination Rule
• How to Fire a Freelancer (and Survive)
• Protect the Business

The "One More Week" Delusion

You are three months into a project that was supposed to take four weeks. You have paid the freelance developer £6,000 so far. The app is barely functional, the code crashes randomly, and the developer takes three days to reply to a simple email.

Every logical part of your brain is screaming at you to fire them. But then the quiet, panicked voice in the back of your head whispers: "If I fire them now, I lose the £6,000. I have to start all over. Maybe if I just give them one more week, they will finally fix it."

Here's the truth: They will not fix it. Welcome to the Sunk Cost Fallacy. It is the number one reason why non-technical founders go bankrupt while outsourcing.

The Poison of the Sunk Cost Fallacy

The Sunk Cost Fallacy is a cognitive bias that makes us continue investing money, time, and emotional energy into a failing endeavor simply because we have already invested so much.

In freelance software development, this bias is lethal. Bad code does not get better over time; it compounds like high-interest debt. If a developer cannot build a functional login screen in month one, they are not going to magically architect a scalable payment gateway in month four.

But it gets worse: Every dollar you spend trying to "save" a broken project is a dollar you are stealing from your startup's future.

The Micro-Win: The "Three Strikes" Termination Rule

To prevent emotional decision-making, you must establish objective criteria for termination before the project even begins. I always advise founders to implement the Three Strikes Rule.

If a developer hits any of these three strikes, you pull the plug immediately. No warnings, no "one more week," no second chances.

Strike 1: The "Radio Silence" Violation

Professional developers communicate. Period. If a developer disappears for 48 hours during a standard workweek without prior notice, they are fired. Why? Because radio silence usually means they are secretly outsourcing your project to a cheaper, unvetted developer behind your back.

Read more: The 'Camera-Off' Red Flag: Why You Must Video Interview Every Freelance Developer

Strike 2: Missing the Micro-Deadline

Never give a developer a massive, three-month deadline. Break the project into strict, weekly micro-milestones. If they agree to deliver the database schema by Friday at 5 PM GMT, and they miss that deadline, it is a massive red flag. If they miss two micro-deadlines in a row, they are fired. A developer who cannot estimate a one-week sprint will absolutely bankrupt a three-month project.

Strike 3: Delivering a Broken Build

When a developer says, "The milestone is complete, please review," they are giving you their professional guarantee that the code works. If you log in to test the milestone and the core functionality instantly crashes, they are fired. This proves they do not write unit tests, they do not perform Quality Assurance (QA) on their own work, and they expect you to be their unpaid QA tester. Look at how elite open-source maintainers on GitHub operate: a PR is rejected instantly if it fails CI/CD checks.

How to Fire a Freelancer (and Survive)

If a developer hits a strike, you must act decisively. Follow this checklist:

1. Revoke Access Immediately: Before you send the termination email, revoke their access to your AWS servers, GitHub repository, and database. Scorned developers have been known to delete source code or hold databases hostage.
2. Cancel the Escrow: Go into your payment platform and dispute the active milestone. You are paying for a working product, not participation effort.
3. Accept the Financial Loss: Yes, you lost the initial money you paid them. Accept it as the cost of learning how to hire properly. It is better to lose £5,000 today than £20,000 next month.

Read more: We Pay for Results, Not Effort: How to Handle Developers Who 'Tried Really Hard'

Protect the Business

Firing someone is never fun, but you are a founder. Your responsibility is to protect the business, your investors, and your future users—not the feelings of an underperforming freelancer.

Establish the Three Strikes Rule, kill failing projects early, and free up your budget to hire the elite technical partner your startup actually deserves.