Switching builders halfway through is expensive, slow, and sometimes exactly the right call. The owners who do it well treat it like moving house: secure the valuables first, then argue about the furniture.
This is general guidance for business owners, not legal advice. If your contract is disputed, talk to a lawyer.
Key Takeaways
- Switch for problems of trust or capability. One late milestone is rarely enough.
- Secure your code, accounts, and data before you announce anything.
- Expect the new team to spend the first week or two understanding the code before building.
- A short paid review of the existing code tells you whether you are continuing or restarting.
Should You Switch at All?
Switching costs real money, because the new team has to learn what exists. Before you decide, be honest about the cause:
| Situation | Usually |
|---|---|
| One slip with a clear reason and a new plan | Stay, cut scope, watch closely |
| Repeated slips with little working software | Get an outside review, then decide |
| Quality is poor and fixes create new bugs | Review, likely switch |
| Builder is unresponsive for weeks | Secure your assets, switch |
| You discovered hidden subcontracting or dishonesty | Switch |
| You and the builder disagree on what was agreed | Go back to the contract first |
If you are unsure, read what to do when your software project is late before acting.
Step One: Secure Your Assets, Quietly
Before telling the current builder, check what you control:
- Code. Is it in a repository you own? Can you see the latest version? If it lives only in their account, ask for a routine export or admin access now, as normal project hygiene.
- Accounts. Domain, hosting, database, payment provider, email service, app store. Who is the owner of each?
- Data. Can you export your customer and business data?
- Documents. Designs, specs, and any notes.
Our list of accounts you should own before a developer builds your app covers each one. If you cannot get to the code, read what to do when a developer won't hand over your code before going further.
Step Two: Get an Independent Code Review
A new developer, paid for a few hours to a couple of days, looks at the code and answers three questions:
1. Can this be continued, or does it need a restart?
2. What works, what is half-built, and what is missing?
3. What would it take to finish the agreed scope?
This review is the most useful money you will spend in a switch. It stops you paying a new team to "finish" something that has to be rebuilt, and it gives you a clear record if the old contract ends in a dispute. See how to audit code a contractor wrote and, if the verdict is mixed, should you rewrite or refactor your app.
Step Three: End the Old Contract Properly
- Check what your contract says about ending early and what you owe.
- Pay for accepted work you owe, and document anything you dispute.
- Ask for a handover: code, credentials, and notes. Use the software project handover checklist.
- Remove their access to your accounts once the handover is done, and change shared passwords.
Keep it professional, and in writing. A calm exit gets a better handover.
Step Four: Brief the New Team
Give them the original scope, the review findings, the list of what is accepted and what is not, and access to everything. Ask them for a fixed price on the remaining work, split into milestones, after they have seen the code. A quote given before seeing the code is a guess.
That is the same basis our software factory works on for any build: a fixed price you approve before work starts, billed per accepted milestone.
A Concrete Version
An owner is four months into a six-month, $40,000 project for a customer portal, has paid $28,000, and has seen very little working software. Updates have become vague.
Step one: the code is in the agency's GitHub. The owner asks for admin access to the repository, which the contract allows, and gets it. The domain and hosting are already in the owner's name.
Step two: an independent developer spends a day on the code. Verdict: logins and document storage work and are sound. File uploads are half-built. Messaging and billing are not started. Estimated remaining work: about ten weeks.
Step three: the contract allows ending with 14 days' notice. The owner gives notice, pays for the one accepted milestone still outstanding, disputes a milestone that was never delivered, and receives the handover.
Step four: a new team reviews the same code, keeps the login and storage work, and quotes the remainder as three fixed-price milestones. The portal launches about three months later. More expensive than the original plan, but the owner kept everything that worked.
The Honest Counterpoint
Many switches happen too early. A new team will always find things to criticize in someone else's code, and it is easy to mistake normal mid-project mess for failure. The same problems (unclear scope, slow decisions on the owner's side) can follow you to the next builder. Before switching, ask what would have to be different for the next team to succeed, and whether any of it depends on you.
Frequently Asked Questions
Can I switch if I paid up front?
Yes, but you have less bargaining power. Focus on getting the code and accounts first, then deal with the money.
Will the new team need to start over?
Not necessarily. The independent review tells you. Often parts are kept and parts are rebuilt.
How long does a switch take?
Allow a week or two for the review and handover, and some time for the new team to understand the code before real progress.
How do I avoid this next time?
Milestone payments, code in your repository from day one, and a named team. Read how to transition from an agency to a dedicated team for a longer-term option.
The Bottom Line
Secure your code and accounts, get an independent review, exit in writing, and brief the new team properly. If you want a plain-English picture of what your project should include before you talk to a new builder, the honest read is free.
Roberto Espinoza is CEO of Ruzora, which builds custom software for business owners at a fixed price and places pre-vetted senior LATAM engineers with US teams. Get a free honest read on your idea.
