The Three Strikes Rule: When to Let a Developer Go

What you actually need to know

• The cost of keeping the wrong developer is not just the salary or the invoice. It is the runway you burn, the momentum you lose, and the second developer you pay to clean up the first one's work.
• Most founders wait two to three months past the point where the evidence was already clear. The hesitation is almost always social, not logical.
• Three strikes is a rule, not a feeling. That distinction matters because feelings about a developer who is personable but unproductive can override data for a very long time.
• The hardest part is honest attribution. Some strikes belong to the developer. Some belong to you. The rule only works if you can tell the difference.
• Letting a developer go cleanly and quickly is a founder skill. The ones who do it well also tend to hire better the next time.

The core argument

The reason founders keep the wrong developer too long is not that they lack the information to act. It is that acting feels disproportionate when the developer is showing up every day, seems to be working, and is a decent person. The social cost of the conversation is immediate. The cost of keeping them is diffuse, spread over weeks, harder to point to. Human brains are bad at that math.

The three strikes rule forces the math. It converts a feeling of "something is off" into a trackable record. When you write down the first missed deadline, you are not punishing the developer. You are creating a reference point. When the second one happens in the same category, you have a pattern, not an incident. When the third one happens, you have an answer. The rule removes the negotiation with yourself that happens in the absence of a frame.

I built the rule out of a mistake I made in my second year of client work. I held onto a contractor for eleven weeks past the first clear signal that the relationship was not working. The signals were all there: late deliveries, answers that were technically plausible but practically useless, and a pattern of waiting for me to ask rather than proactively flagging problems. I rationalized each one. He is working through something. The project is harder than I scoped. He will turn it around. He did not. The project ran four months over, and the client paid twice, once for the work and once for the audit of the work.

The three strikes rule is not punitive and it is not personal. A developer who earns three strikes in one engagement is not necessarily a bad developer. They might be a good developer who is wrong for your project, wrong for your communication style, or just in a difficult period. The rule does not require you to form a judgment about their worth as an engineer. It only requires you to protect your project.

The three categories of strikes

Category one: delivery failures

A delivery failure is a missed deadline that arrived without warning. The key word is without warning. If a developer tells you on Tuesday that the Friday delivery is at risk, that is not a strike. That is communication. If you find out on Friday that the Tuesday work is not done, that is a strike. The pattern you are watching for is whether the developer surfaces problems early enough for you to do anything about them.

Category two: communication failures

A communication failure is a blackout, an unexplained delay in response, or a pattern of answers that are technically accurate but practically useless. Twenty-four hours of silence on a normal working day is a yellow flag. Forty-eight hours without explanation is a strike. The threshold compresses as the urgency of the work increases.

Category three: quality failures after clear requirements

This is the hardest category to attribute correctly, because quality failures are often shared. If the requirements were vague, the rework is partly yours. If the requirements were written down, agreed upon, and the work still required significant correction, that is a strike. The distinction matters because misattributing a strike to the developer when it belongs to you destroys trust and poisons the relationship beyond recovery.

How much does it cost

These numbers are ranges I have seen on projects I have either worked on or been brought in to repair. The cost of waiting compounds nonlinearly. Each week you hold on past strike three is a week of new code written in a pattern you will eventually need to change.

What to look for when you are approaching strike three

• The developer consistently waits for your questions rather than proactively surfacing problems. That pattern does not usually improve on its own.
• The direct conversation happened, both of you left understanding the expectation, and the next two weeks did not change. Direct conversation with no behavioral change is the clearest third strike there is.
• You have started editing the developer's work before sharing it with other stakeholders. If you are doing that, you already know the answer.
• Other people on the project are routing around the developer rather than through them. That is a team signal, not just a founder feeling.
• The project timeline is expanding in ways that are only partially explained by scope changes.

Expert opinion

The developers I have had to let go were almost never bad developers. They were developers who were wrong for the project, wrong for the stage of the company, or working in a relationship that the founder had not structured clearly enough to succeed. The honest version of the three strikes rule requires the founder to ask, for each strike, whether they caused it. That question is uncomfortable. It is also the most useful thing you can do.

>

Yashveer Singh, founder of Yashveer Labs

How this played out on a real project

A founder I work with hired a contractor based on a strong portfolio and good references. The first four weeks were clean. Week five brought the first missed handoff, no warning, no explanation until asked. The founder noted it and said nothing formal. Week seven brought a communication blackout over a long weekend that bled into Tuesday. The founder sent a message, got a plausible explanation, and moved on. Week nine brought a module that required three days of rework because the contractor had built against the old API spec rather than the revised one that had been shared in writing.

Three strikes, clearly attributed. The founder let the contractor go at the end of week nine. The transition took four days. The new contractor, found through a referral from someone I had worked with on a similar project, picked up the codebase in a week. The final product launched six weeks later. The delay was real. The alternative, which was continuing to hope the pattern would change, would have been longer.

For the process of bringing in someone new after a departure, the vetting framework covers how to structure the evaluation. For the cost math of switching mid-project, the post on the true cost of a rewrite gives you a framework for the decision.

Common mistakes

1. Waiting for a definitive fourth or fifth failure before acting. The rule is three. The rule exists precisely because you will always be able to find a reason to wait one more week.
2. Counting ambiguous strikes. If you cannot clearly attribute the failure to the developer rather than the requirements, it does not count. Clean strikes only.
3. Having the "something is off" conversation without being specific. Vague feedback does not change behavior and does not generate a clean strike record.
4. Not getting production access before the offboarding conversation. Do this first, every time.
5. Letting the departure conversation become a negotiation about a second chance. The third strike is a decision, not an opening position.
6. Blaming the developer for problems that were fundamentally scope or communication failures on your side. Honest attribution protects you from making the same mistake with the next hire.
7. Skipping the post-departure codebase audit. You need to know what you are working with before you bring in someone new.
8. Not asking yourself what you would do differently in the hire. The three strikes retrospective is as much about your process as it is about the developer.

A 3-week transition plan

1. Before the conversation. Confirm you have access to every production account: repository, hosting, database, domain, API keys. Write a one paragraph summary of where the project stands and what the next developer will need to know. This is for you, not for them.
2. The conversation. Direct, short, and specific. Name the three instances. Explain the decision. Give a clear end date, usually one to two weeks to allow for handover. Do not negotiate the decision itself.
3. Week one after. Request a written handover document covering system architecture, open issues, and access credentials. Have an independent developer spend two to three hours auditing what was built.
4. Week two after. Begin the search for a replacement using the lessons from this hire. The hiring questions post is the right place to rebuild the screening process. For the cost of this transition relative to earlier action, the post on why cheap developers cost the most long term makes the math visible.