8 Signs It's Time to Fire Your Developer
Your developer says everything's fine. Your gut says it isn't. One of you is wrong, and it's worth finding out before it costs you more than a bad feeling.
Most "signs to fire your developer" lists read like an agency describing anyone but themselves — vague complaints, nothing you could point to. This is what a real technical review actually catches.
Also weighing what comes next — freelancer, agency, or something in between? We've written about that separately. Read this one first, though — firing well matters more than hiring well.
Sign 1: They Can't Explain What They Built, in Plain Language
- If "how does this work" turns into an unrelated tangent about frameworks, that's a stall, not an explanation.
- A developer who understands their own system can walk you through it in two minutes without jargon. One who can't, usually can't defend it under review either.
Sign 2: Every Fix Creates Two New Bugs
- One patch on another, without addressing why the first was needed, is technical debt compounding in real time.
- Watch the pattern, not the incident. One bug is normal software. A bug needing three follow-up bugs is a structural problem.
Sign 3: You Only Get Reassurance, Never Specifics
- "It's handled," "don't worry about it," "that's normal" — none of those are answers.
- A real answer names the actual cause and the actual fix. Can't get one after asking twice? That's the answer — the same signal that shows up in how a remote team communicates day to day.
Sign 4: Nobody Else Can Touch the Code but Them
- No documentation, no handoff notes, nothing another developer could pick up without a week of archaeology — that's control, not competence.
- Ask what happens if they vanish for two weeks. No real answer means you don't fully own your product.
Sign 5: Problems Get Hidden, Not Fixed
The difference between a caught bug and a real catch is specificity. In one of our own products, a payment webhook verified its signature against the wrong bytes. Every automated check technically passed. Upgrades customers had already paid for were silently never applied — nothing crashed, nothing alerted, it just failed quietly for months. We broke this exact bug class down here.
- "We tested it and it works" often means it passed the test someone wrote, not the scenario that happens in production.
- Ask what happens on a malformed request, not just a correct one. The answer tells you more than any demo.
Sign 6: Security Gaps Get Waved Off as Edge Cases
We've also caught an IDOR — changing an ID in a URL let one account see another account's private data, because nothing on the server checked who was actually allowed to see it.
- "That's unlikely" instead of "here's how we checked" isn't a security posture. It's a bet placed with your customers' data.
- You don't need to be a security expert — just alert enough to notice when an answer isn't really an answer.
Sign 7: Deadlines Move, But the Scope Never Shrinks
- A slipping deadline with a shrinking, clarified scope is normal. The same slip with the same scope, restated with more confidence each time, is not.
- If the actual problem was never written down in one paragraph, the timeline was never real — a guess dressed up as a date.
Sign 8: You're Afraid to Ask for a Second Opinion
- If part of you doesn't want another developer looking at the code, that instinct is data. Good work survives a second look; over-patched work usually doesn't.
- A second opinion doesn't have to mean confrontation — a quiet, independent review tells you what you're dealing with before the harder conversation.
Before You Actually Fire Anyone
Firing first and figuring out the damage after means paying twice — for the bad work, and to have someone else untangle it blind.
- Week 1 — Get an outside technical review: the code, the data model, what's genuinely broken versus what just looks messy.
- Week 2 — Get a plain-language explanation of the findings, translated for you, not for another engineer.
- Week 3 — Decide, with that information, whether this is a conversation, a handoff, or a full replacement.
- Week 4 — If it's a replacement, hand the new team a real starting point, not a guess.
What to Measure Once You've Switched
- Whether questions get specific answers, on the first ask.
- Whether the bug rate actually drops, or just moves somewhere new.
- Whether you can get a plain-language explanation of your own product, on demand.
- Whether the knowledge stays with you, not just with whoever's coding.
If You Want ZPro to Build This With You
At Zdravevski Professionals, this is close to a specialty: coming in after something has gone quiet-wrong and telling you plainly what's there. We can:
- run an independent technical review of an existing codebase, with no assumptions carried over from whoever built it
- explain what we find in plain language, not a report written to impress other engineers
- tell you honestly if the fix is smaller than you fear, or bigger than you've been told
- take the handoff and keep building, once you can actually see what you're working with