Founder lessons: when to fire your developer

The hardest email I ever had to write was not to a client. It was to a developer I had hired, who I liked, who was not working out, and who I had let drift for three months longer than I should have because ending it felt like failure. Knowing when to fire your developer is a skill nobody teaches founders, and most of us learn it the expensive way. So this is the honest version, written from the side of someone who has both made the call and botched the timing.

The uncomfortable truth is that founders almost never fire too early. We fire too late. We explain away the warning signs because the alternative, starting again, is so daunting that denial feels cheaper. It is not.

The signs that are actually serious

Not every problem is a firing offence. Software slips. People have bad weeks. The question is whether you are looking at a solvable wobble or a pattern. These are the patterns I have learned to take seriously.

Communication going quiet is the loudest one. When a developer is doing good work, they tell you. When things are going wrong, the updates get vague, then slow, then stop, and you find yourself chasing for news. A developer who has gone quiet is almost never quietly smashing it. They are usually stuck and hoping you will not notice yet.

Every answer becoming a reason why not is another. Good developers push back, that is healthy, but they push back and then propose a path. If every request comes back as an obstacle with no alternative offered, you have someone managing your expectations downward rather than solving your problem.

The demo that never quite works is the third. You ask to see progress and there is always a reason it cannot be shown today. Real progress can be shown. Repeated excuses for why it cannot usually mean there is less under the hood than the invoices suggest.

And the money and the output drifting apart is the one that finally forces the issue. When you genuinely cannot see what the last month of fees bought, and asking produces a fog rather than a feature, trust is already gone. If you are struggling to even judge this, our guide on how to evaluate a developer’s portfolio and work applies just as well to work in progress as to a hiring decision.

Separate the fixable from the fatal

Before you pull the trigger, be fair, to them and to yourself. Some of what looks like a developer problem is actually a founder problem wearing a disguise.

If the brief kept changing, the slipping deadlines might be scope creep you caused, not incompetence they showed. If you never agreed how often you would hear from them, the silence might be a gap you left open. I have blamed developers for things that were, honestly, my unclear instructions. Our post on managing a remote app project covers the structure that prevents most of these, and it is worth reading before you decide the person is the problem.

So have the direct conversation first. Name the specific pattern, not a vague unease. Say what has to change, by when, and what good looks like. A developer worth keeping responds to that with relief and a plan. One who gets defensive, vague, or offended has told you most of what you needed to know.

When it really is time

If you have been fair, been specific, given a genuine chance to fix it, and the pattern continues, it is time. The signal I trust most is simple: you have stopped expecting things to get better. When your honest internal forecast is “this will keep going like this”, the decision is already made, you are just catching up to it.

Waiting longer does not protect your investment. It compounds the loss. Every extra month of fees for work you cannot see is money gone, and worse, it is time your app is not reaching users. The sunk cost is already sunk. The only question left is how much more you add to it.

How to end it without wrecking the app

Firing badly can turn a disappointment into a disaster, because your code and your knowledge are often inside that person’s head and accounts. So end it deliberately.

Before you say anything, make sure you control the essentials: the code repository, the hosting and app store accounts, the domain, and the designs. If those are in the developer’s personal accounts, get them transferred first, as a normal handover, before the conversation that makes handover awkward. I have seen a founder locked out of their own app because they fired the one person with the passwords. Do not be that founder.

Then be straight and professional. You do not need to litigate every grievance. “This is not working out and we are going to part ways” is enough. Ask for a clean handover, a written note of what is done and what is not, and the credentials. Pay what you genuinely owe. A calm, fair exit gets you a cooperative handover, and a cooperative handover is worth far more than the satisfaction of a sharp word.

What I would tell my earlier self

Trust the quiet. The month where you first thought “something feels off” and talked yourself out of it, that was the signal, and the three months after it were the price of ignoring it. Founders are optimists by trade, and optimism is exactly what makes us slow to see a relationship failing.

You are not firing a person because you are cruel. You are protecting the thing you are building, which is your actual job. The developers I respect most understand that completely, because they would do the same in your position.

What to do next

If you are reading this because something already feels off, that feeling is data. Have the specific conversation, give a real chance, secure your accounts, and if the pattern holds, act without waiting for a disaster to force you.

And if you have just parted ways and need a team to pick up an app that is half-built and poorly documented, send us a project brief. Inheriting other people’s code is a large part of what we do, and the first thing we will do is tell you honestly what you actually have.