There's no shortage of advice telling you to fire your agency. "If they miss deadlines, cut them." "If the code quality is bad, move on." "Don't throw good money after bad."
What that advice never includes is a line item for what switching actually costs.
The frustration is real. A missed deadline feels like a failure. Slow communication feels like disrespect. But frustration is not a budget. And replacing one agency with another mid-project is one of the most expensive decisions you can make — even when it's the right one.
Here's what you're actually paying when you switch.
Sunk Cost vs. Switching Cost — Two Different Problems
Most founders who switch agencies mid-project are thinking about sunk cost: the money they've already spent on work that isn't working. That's a real number, and it's painful.
But sunk cost is a fixed loss. You've already paid it. The switching cost is what you're about to pay — and it's rarely calculated before the decision.
Switching cost includes: the time to onboard a new agency, the ramp-up period before they're productive, the code archaeology required to understand what they're inheriting, the bugs introduced during the handover, and the weeks of velocity lost while the new team figures out what the old team built.
Most clients focus on getting out of a bad situation. Few pause to ask: how bad is the getting out, exactly?
What Gets Lost When an Agency Leaves
Software projects accumulate something that never shows up in a contract: context.
Context is the understanding of why decisions were made, not just what decisions were made. Why is the authentication flow structured this way? Why was that third-party integration avoided? Why does this module have that unusual timeout? The answer is usually buried in a Slack thread from three months ago, or in the head of a developer who's no longer on the project.
When an agency exits, that context goes with them. The new agency inherits code — not understanding. They'll read the files. They won't read the reasoning.
This gap translates directly into time. A new team needs to reverse-engineer decisions that took the original team weeks to arrive at. They'll make assumptions where they should have certainty. Some of those assumptions will be wrong, and you'll find out later — often in production.
Beyond context, you also lose:
- Documentation — if it existed. Many agencies produce thin docs under deadline pressure.
- Code conventions — naming patterns, folder structures, patterns that are internally consistent but undocumented.
- Relationship capital — the informal trust that makes communication fast. A new agency starts at zero.
- Tribal knowledge — what the team knows about your business, your users, your priorities. That knowledge took time to build.
None of this is recoverable by sending over a GitHub repo.
The Hidden Time Tax
Here's a number most clients underestimate: a competent new agency needs four to eight weeks before they're truly productive on an inherited codebase.
This isn't because they're slow. It's because understanding someone else's code — written under different assumptions, with different conventions, by people who aren't around to answer questions — takes time. Good engineers take that time seriously because the alternative is shipping bugs.
During those weeks, you're paying the new agency. You're also losing the weeks themselves — weeks that were supposed to be sprint time, not onboarding time.
If your original agency was four weeks behind schedule, and the new agency needs six weeks to ramp up, you haven't solved a problem. You've extended it.
Add the time to evaluate and select a new agency (typically two to four weeks of your time, not theirs), negotiate a new contract, migrate credentials and access, and brief the new team on the product — and you're looking at a real-world delay of two to four months before the new agency is delivering at full speed.
That's the time cost. The money cost runs parallel to it.
When Switching Is Actually Worth It
All of this argues for staying, right? Not exactly.
There are situations where switching is the correct call — and where the switching cost, while real, is still lower than the cost of staying.
You should seriously consider switching when:
The code quality is fundamentally broken. Not behind, not rough — broken. If what's been built is architecturally unsound, or if the technical debt is so severe that any new feature requires rebuilding what's underneath it, staying is more expensive than leaving.
Trust has collapsed. Communication has stopped. Commitments are made and not kept. Explanations don't match reality. An agency relationship without trust isn't a partnership — it's a drain.
Scope has drifted beyond repair. If what's being built is no longer what you need, and the agency can't (or won't) adjust course, staying means finishing the wrong product.
The agency itself is dissolving. Team turnover, leadership departure, financial instability — these are signs that the continuity you need doesn't exist regardless of what the contract says.
In these cases, switch. But switch with eyes open. The switching cost is still real. You're not avoiding it; you're deciding it's worth paying.
How to Protect Yourself — Regardless of Which Agency You Use
The best protection against the cost of switching is making switching cheaper before you ever need to do it. That means building in from day one:
Documentation requirements in the contract. Not "we'll document it at the end." Weekly documentation, milestone-gated. Architecture decisions recorded, not just made.
Code reviews at regular intervals. Not just internal reviews — bring in an outside eye at 30%, 60%, and 90% of the build. This catches architectural drift early, when it's cheap to correct.
Shared knowledge channels. Your team should have read access to the project communication (or at minimum, a regular written brief) so knowledge doesn't live solely on the agency's side.
Staged access and credential control. You should own all credentials, environments, and repositories from day one. This is non-negotiable. The moment you need to switch, you shouldn't also be fighting for access.
Honest milestone reviews. Every major milestone is a natural stopping point. Evaluate at each one — not just the deliverable, but the relationship and process health. Small problems caught at milestone two are a conversation. The same problems caught at milestone five are a crisis.
The Takeaway
Switching agencies is sometimes the right move. But it's never the free move. It costs time you didn't plan to spend, money you didn't budget, and momentum you'll have to rebuild.
Before you make that call, do the math. Not just on what you've lost with the current agency — on what you're about to spend on the next one.
The agencies worth staying with are the ones that make switching unnecessary. They communicate early when something is wrong. They document as they go. They treat your codebase like something they'd have to hand back — because they know they might.
That's the kind of agency that protects your project regardless of how the relationship ends.
