How to Fire Your Dev Agency Without Losing Your Product

You’ve decided. The trust is gone, and you’re moving to another team. Good. But the email you’re about to send is the most dangerous move in the whole breakup, and the reason is timing.

Right now, while they don’t know, you hold the leverage. The day you tell them, it flips. A team that answered in an hour starts answering in a week. Access requests stall. The code you assumed was yours turns out to live in a GitHub org you were never actually added to. None of this is paranoia. It’s just what happens when the incentive to help you disappears and the incentive to protect their position takes over. We’ve pulled four separate products out of agency builds that went exactly this way, and the founders who got out clean all did the same thing: they prepared before they said a word.

So you do this in the right order. You prepare in silence, get everything genuinely in your hands, and only then break the news. Fire the agency before you’ve secured your product and you’ve handed them the one thing you can’t afford to give up: time to make leaving expensive.

Prepare Before You Say a Single Word

This is the whole game. Everything that matters happens before the conversation, quietly, while the relationship still looks normal from their side. If you’ve read how to actually own your code, this is the recovery version, for when you didn’t set it up cleanly and now have to get it back without tipping anyone off.

Work through these in order, and don’t announce anything until every one is genuinely done, not promised.

Get confirmed admin access to the code repository. Not a zip file. Not “we’ll send it over.” Admin access to the live repository, in an organisation you control, with the full commit history. Log in yourself and check you can see it. If the code sits in their GitHub org, this is the single most important thing to move first, and the hardest to get once they know you’re leaving.

Get the deployment and hosting. The place your product actually runs: the servers, the database, the hosting account. You need real access, ideally ownership. If the app lives on their infrastructure, “turn my product back on” is the worst sentence you can be forced to say, and you never want to be in a position to say it.

Get the domain and DNS. Your domain, in an account with your name on it, with control of the DNS records. This one gets forgotten until the day a developer’s personal registrar account is the only thing standing between your users and your product.

Get every third-party service account. Payments, email, analytics, storage, error monitoring, anything with a login. Each one under your company’s billing and your credentials. Your Stripe account holds your money. Your email service holds your ability to reach your own customers. You do not want either sitting under someone else’s personal email on the day you leave.

Make Sure You Have the Real Thing, Not a Photograph

Access is not the same as having the code. A stale zip, an old branch, or a repo that’s missing the last month of work will feel like ownership right up until your new developer tries to run it and nothing builds.

So verify. Check that the most recent commits match what’s actually live in production. Confirm the deployed app was built from the code you can see, not from some local machine you’ll never have access to. Best of all, have your next developer or a bridge engineer pull the code and stand it up before you announce anything. If it runs, you have your product. If it doesn’t, you have a warning, while you still have the leverage to do something about it.

Line up what comes next. Don’t fire your team into a vacuum. Have the next agency, in-house developer, or at minimum a bridge engineer ready to take over, someone who can keep the product alive and answer questions while you transition. Even a few weeks of a capable freelancer holding things together beats a hard stop with nobody at the wheel.

Re-read your contract, specifically two clauses. The termination clause tells you how much notice you owe, what you’re on the hook for, and how the relationship formally ends. The IP assignment clause tells you whether the code is legally yours. Know both cold before you write the email, so nothing in their reply catches you off guard.

Then, and Only Then, Break the News

Once everything is genuinely in your hands, the conversation becomes a formality instead of a fight. That’s the entire point of the preparation. You’re not asking them for anything you can’t already get, so there’s nothing left to hold over you.

Do it in writing. Keep it short, professional, and unemotional. Thank them for the work, state clearly that you’re ending the engagement, give a specific last day, and request a defined handoff: documentation, any remaining credentials, and a short window for your new team to ask questions. No grievances, no long explanation, no bait for an argument. A clean, dated, written message that leaves nothing to interpret.

Resist the urge to vent, even when it’s deserved. You may still need these people for a question in three weeks, and a bridge you burned on the way out is one you’ll wish you had back. Professional and slightly warm costs you nothing and keeps the door open for the transition to go smoothly.

If They Turn Hostile or Hold Things Hostage

Most exits are smoother than founders fear. But if you skipped the preparation, or a team decides to be difficult, you can find yourself locked out of your own product. Here’s how to handle it without losing your head.

I have seen both versions of this up close. In the good one, everything was where it should be: documentation in place, several proper handover sessions, genuinely smooth. In the bad one, there was no one left to talk to. No tests, no documentation, just a codebase and weeks of our time spent working out how it even ran. And a third, somewhere in between: the founders had no repository access at all, so the only way in was through their old developers, except the founders did not know what to ask them, so we had to translate. The difference between those exits had almost nothing to do with the code and everything to do with what had been secured, and written down, before anyone announced they were leaving.

Stay calm and put everything in writing. Hostile negotiations happen over the phone where there’s no record. Move it all to email. A clear, unemotional paper trail is your best protection, and difficult people behave better when they know it exists.

Lead with your contract, not your anger. If the IP assignment clause makes the code yours, state that plainly and ask for the specific access it entitles you to. You’d be surprised how often a calm, accurate reference to the agreement they signed ends the standoff. If it doesn’t, that same contract is what your lawyer will use, and a firm letter from one is often cheaper and faster than the fight you’re dreading.

Pay what you genuinely owe, and not a penny of invented ransom. There’s a difference between a legitimate final invoice and a sudden new fee that appears the moment you try to leave. Settle the first without drama. Don’t reward the second.

This is where honesty about our own interest matters: a technical partner worth hiring, us included, makes leaving easy on purpose, because confidence in the work means never needing to trap the client. When you choose who comes next, watch how they set up ownership on day one. That, more than any promise, tells you whether you’ll ever have to read an article like this again.

Are You Ready to Make the Call?

Before you send anything, run through this. Every box should be ticked before the news leaves your hands, not after.

Firing a dev agency well is not about the confrontation. It’s about making the confrontation irrelevant. Do the quiet work first, get every piece of your product into accounts you control, verify it actually runs, and line up who comes next. Then the email that ends it is just paperwork, and you walk away with the one thing that was always the point: your product, fully in your hands.