Firing the person building your product is one of the most frightening things a non-technical founder can do — because it feels like firing the one person who understands the thing your business depends on. So founders wait too long, hoping it'll turn around, while the project quietly bleeds.
This is how to know when it's actually time, and — just as important — how to leave without losing your codebase, your data, or your business in the process.
The signs it's genuinely time
Not "we had a rough sprint." Real, repeated patterns:
- The demos keep getting talkier. As I wrote in watching the build without being technical, the danger sign isn't a missed date — it's weeks of "here's where it will go" with less and less you can actually click.
- Questions are met with defensiveness, not answers. A good developer welcomes "can you show me?" Someone stalling treats every reasonable question as an attack.
- The estimates have stopped meaning anything. Everything is "almost done" for the third month running.
- You've lost trust, and it isn't coming back. Trust your gut here. If you dread the weekly call, that's data.
One bad month is a conversation, not a firing. A pattern across months, after you've raised it directly and nothing changed — that's your answer.
Before you say a word: get your house in order
Here's where founders get hurt. They fire in a burst of frustration, and only then discover the code lives in the developer's personal account, the hosting is on the developer's credit card, and the domain is registered to the agency. Now you're not negotiating an exit — you're a hostage.
Do this quietly, before the conversation:
- Confirm every account is in your name. Code repository, hosting, database, domain, third-party services. If you did the hiring right, this is already true. If not, fix it before you give any signal you're leaving.
- Get a current backup of the code and the database. Downloaded. In your possession. Today.
- Write down what you don't know. Where things are hosted, what services are connected, what passwords exist. You're about to lose the person who holds it all in their head.
Until you own the keys, you don't have leverage — you have hope. Don't start the conversation until the keys are yours.
Make the exit a clean handoff, not a fight
Even when you're angry, the goal is a transition, not a war. A developer who leaves on reasonable terms will document, answer questions, and hand off cleanly. One who feels ambushed can make the next three months miserable in a hundred small ways. So:
- Be direct and unemotional. "This isn't working and we're going to part ways. I want to do it cleanly and fairly."
- Ask for a handoff document. How to run it, deploy it, where everything lives. Pay for this time — it's the cheapest insurance you'll buy.
- Have the next developer ready to receive it. Ideally they overlap, even briefly, so knowledge transfers human-to-human instead of dying in a chat log.
The replacement will tell you the truth about what you had
When the new developer opens the codebase, you'll finally learn whether the old situation was bad luck or bad work. Either way, resist the urge to rebuild everything on day one — a good replacement triages first: what's salvageable, what's dangerous, what can wait. If you're weighing who to bring in next, the solo-versus-agency math changes once you have a real product to protect rather than a blank page.
What to take from this
- Fire on patterns, not on a bad week. Repeated talky demos, defensiveness, meaningless estimates, dead trust.
- Own every account before you say anything. Keys first, conversation second. No exceptions.
- Aim for a handoff, not a fight. Pay for documentation and an overlap; it's the cheapest part of the whole mess.
- Don't let the new dev rebuild on reflex. Triage beats teardown.
Done right, firing a developer costs you a hard week and a transition fee. Done wrong — keys in someone else's name — it can cost you the company. The difference is entirely in the preparation.
If you suspect it's time but you're afraid of what leaving will cost you, talk to me before you do anything. I'll help you secure your codebase first and plan a clean exit — and tell you honestly whether it's a firing situation or a fixable one.
