How to Fire a Developer

Nobody Wants to Fire Someone (But Sometimes You Must)

Firing a developer is:

• Uncomfortable (for both sides)
• Expensive (lost time, knowledge, money)
• Necessary (if the fit isn't working)

Keeping a bad developer is more expensive than firing them. Every week you wait costs you time and money.

Warning Signs It's Time to Fire

Performance Red Flags

• 🚩 Consistently misses deadlines by 2-3x
  • Not once - everyone has a bad week
  • Pattern over 3-4 weeks
• 🚩 Code quality is poor despite feedback
  • Same mistakes repeatedly
  • Ignores code review comments
  • Introduces more bugs than features
• 🚩 Lack of progress
  • "Still working on it" for weeks
  • Can't show tangible results
• 🚩 Doesn't follow instructions
  • Builds something different than requested
  • Ignores priorities

Communication Red Flags

• 🚩 Goes silent for days
  • Doesn't respond to messages
  • Misses scheduled calls
• 🚩 No proactive updates
  • You always have to ask "What's the status?"
  • Surprises you with bad news at deadlines
• 🚩 Defensive or combative
  • Can't take feedback
  • Blames tools, requirements, "scope creep"

Trust Red Flags

• 🚩 Lies about progress
  • "It's done" but it's not
  • "I'm testing it" for days with no results
• 🚩 Padding hours (if hourly)
  • Claims 8 hours on a 2-hour task
  • Can't explain what took so long
• 🚩 You dread every interaction
  • If you're avoiding checking in, that's a sign

The "One More Chance" Framework

Before you fire, give ONE clear warning:

Step 1: Document the Issues

• Write down specific examples (dates, tasks, outcomes)
• Be objective: "Task X was due May 1, delivered May 8, still had 3 bugs"
• Not subjective: "You're always late"

Step 2: Have the Conversation

Be direct and specific:

"I need to address some concerns. Over the past 3 weeks, we've had these issues: [list specifics]. Here's what needs to change: [clear expectations]. If we don't see improvement in the next 2 weeks, we'll need to part ways. Do you have questions or concerns?"

Step 3: Set a Clear Deadline

• Timeline: 1-2 weeks (not open-ended)
• Metrics: Specific improvements needed
• Check-in: Schedule follow-up conversation

Step 4: Evaluate

After 1-2 weeks:

• Did they improve? → Continue
• No improvement? → Time to fire
• Slight improvement but still not enough? → One more week MAX

Exception: Skip the warning if there's dishonesty, breach of contract, or they disappear.

How to Have the Firing Conversation

Prepare First

• Review contract: Notice period, payment terms
• Decide final payment: What do you owe them?
• Plan transition: Do you need code handoff?
• Backup code: Export everything NOW (before the call)

The Script

Keep it short and professional:

"After our last conversation, I've been evaluating the progress. Unfortunately, I don't think this is working out. I've decided to end our working relationship. Your last day will be [date]. I'll send payment for [hours/work completed] by [date]. Can you please [hand off code/documentation] by end of day?"

What NOT to Say

• ❌ "This is harder for me than for you" (it's not)
• ❌ Long explanations or justifications (don't JADE - Justify, Argue, Defend, Explain)
• ❌ "Let's stay friends" (awkward and insincere)
• ❌ "It's not you, it's me" (you're not breaking up, you're firing them)

If They Push Back

• "Can I have another chance?"
  • "I gave you that chance [reference previous conversation]. My decision is final."
• "This is unfair!"
  • "I understand you're upset. Here's what we agreed on [reference contract/expectations]."
• "I'll sue!"
  • "That's your right. Our agreement is [reference contract]. I'll send final payment as stated."

Stay calm. Don't get emotional. Don't argue. State your decision and move on.

Protecting Your Code and IP

BEFORE the Firing Call

Critical: Do this FIRST

1. Export all code from repositories
   • Download full repo backup
   • Export any hosted files/databases
2. Change all passwords/access
   • Repository access
   • Hosting accounts
   • Database passwords
   • API keys
   • Domain registrar
3. Verify code ownership
   • Code commits are in your repo (you own it)
   • Not on their personal account

Horror story: Developer deleted the entire codebase after being fired because founder didn't revoke access first.

After the Call

• Immediately remove all access (if you didn't already)
• Change any credentials they knew
• Verify they can't access anything

Transition Planning

If You Need Code Handoff

Option 1: Paid handoff session (if parting amicably)

• Pay for 2-4 hours of their time
• Have them walk through code
• Document key decisions/quirks

Option 2: Skip the handoff (if relationship is bad)

• Just get the code
• Next developer reverse-engineers it
• Budget 20-30% extra time for new dev

Finding a Replacement

Move quickly but don't panic-hire:

• Use your previous hiring process
• Mention it's a "taking over existing project" role
• Show them the code early (transparency about code quality)
• Budget for ramp-up time

Legal Considerations

Check Your Contract

• Notice period: Do you owe 1-2 weeks notice?
• Severance: Do you owe anything beyond work completed?
• IP ownership: Confirm code ownership clause
• Non-compete: Can they work for competitors? (Usually not enforceable for contractors)

Payment

Pay what you owe, nothing more:

• Hours worked (if hourly)
• Milestones completed (if milestone-based)
• Any contractual severance
• Do NOT pay for incomplete work "to be nice"

U.S. vs International Developers

• U.S. contractors: Usually at-will (can fire anytime unless contract says otherwise)
• International contractors: Check local laws (some countries have stronger contractor protections)
• Generally: Contractors have fewer protections than employees

Not legal advice - consult a lawyer if you're unsure about your specific situation.

After You Fire: What's Next?

Immediate Actions

1. Secure all access (if not already done)
2. Send final payment promptly (within 7 days)
3. Start hiring replacement
4. Assess damage: What needs to be rebuilt/fixed?

Learn from It

• What were the early warning signs? (Watch for them next time)
• Did you wait too long to act? (Fire faster next time)
• Was your hiring process flawed? (Add trial tasks? Better vetting?)
• Were expectations clear? (Improve onboarding?)

When NOT to Fire

Give grace for:

• One-time personal emergency (death in family, medical issue)
• Misunderstanding that's quickly corrected
• Honest mistake if they take ownership and fix it
• Learning curve on genuinely complex problem

Pattern vs incident:

• One late delivery → Have a conversation
• Consistently late → Fire

The Emotional Side

You will feel:

• Guilt ("Did I give them enough chances?")
• Doubt ("What if I'm wrong?")
• Relief (if it was particularly bad)
• Anxiety ("Now I'm back to square one")

Remember:

• Business relationships are transactional
• Keeping a bad developer hurts your business
• Most firings are mutual - they're probably unhappy too
• You'll find a better fit

"Hire slow, fire fast" - Once you know it's not working, act quickly.

Firing Checklist

Before the Call

• ☐ Document all issues with specific examples
• ☐ Review contract (notice period, payment terms)
• ☐ Backup all code and files
• ☐ Change all passwords and revoke access
• ☐ Calculate final payment owed
• ☐ Prepare transition plan

The Call

• ☐ Keep it brief and professional
• ☐ State decision clearly (don't waver)
• ☐ Specify last day and final payment date
• ☐ Request code handoff (if needed)
• ☐ Don't argue or over-explain

After the Call

• ☐ Verify all access revoked
• ☐ Send final payment promptly
• ☐ Export/backup any remaining files
• ☐ Begin replacement search
• ☐ Assess what needs to be rebuilt