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

You are three months into a project that was supposed to take four weeks. You have paid the freelance developer $8,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 $8,000. I have to start all over. Maybe if I just give them one more week, they will finally fix it."

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 "One More Week"

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 compound 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.

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

The "Three Strikes" Rule of Freelance Development

To prevent emotional decision-making, you must establish objective criteria for termination before the project even begins. In my experience rescuing failed outsourced projects, I always 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, and they are waiting for that person to deliver the code.

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, 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.

How to Fire a Freelancer (and Survive)

If a developer hits a strike, you must act decisively.

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 Upwork or 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.