How do you switch software development companies mid-project?

Your app is late, the updates have gone quiet, and every fix seems to break something else. You are starting to wonder whether to bring in someone new. You are not the first business in this spot, and it is usually more fixable than it feels.

Here is the short answer. Before you tell your current developer anything, make sure you control the code repository, hosting, domain, app store accounts and every admin password. Then have a new team audit the code before you decide whether to continue it or rebuild. Expect the first few weeks with a new developer to go into learning the code, not shipping features.

What are the signs a software project is failing?

One bad week is normal. A pattern is not. Watch for:

• Deadlines slip again and again, each time with a new reason
• You can't see working software. Updates are status reports, not demos you can click
• Bugs come back after being marked fixed
• Simple changes take weeks, which often means the code is fragile
• Communication goes quiet or only one person on their side understands the system
• Invoices grow but the product doesn't
• You don't have access to the code or hosting, and requests for it get delayed

If three or more of these sound familiar, it is worth a frank conversation, and worth preparing for a switch even if you hope you will not need one.

Should you switch or try to fix it?

Sometimes the problem is fixable. A missing spec, unclear priorities or a single overloaded developer can often be solved with a reset meeting, a written plan and a demo every two weeks. Give that a short, defined trial (say, one month with clear goals).

Switch when trust is gone, when the same promises keep failing, or when the developer will not give you access to what you have paid for. If you are at that point, read on, and do the steps in order.

Much of this pain comes from a thin agreement. For the next project, see what a website development contract should include.

What should you secure first?

This is the most important part of the whole process. Do it quietly, before you announce a change. Most handovers go wrong because the business owner did not control its own accounts.

1. Code repository. You should be an owner (not just a viewer) of the GitHub, GitLab or Bitbucket account or organization that holds the code. Check that it includes every repository: web app, mobile app, backend, scripts.

2. Hosting and cloud accounts. AWS, Google Cloud, Azure, Vercel, Supabase, Heroku, or whatever runs your app. The account should be in your company's name, with your card on file and your email as an owner.

3. Domain and DNS. Your registrar account (GoDaddy, Namecheap, Cloudflare) should be yours. Whoever controls DNS controls where your site and email point.

4. App store accounts. Apple App Store Connect and Google Play Console. If your app was published under the developer's account, moving it takes time, so start early.

5. Third-party services. Payment processor, email sending, maps, SMS, analytics, error tracking. List every service and confirm who owns each account.

6. Credentials and secrets. API keys, database passwords, encryption keys. Get them into a password manager your company controls.

7. Documentation. Whatever exists: setup instructions, architecture notes, a list of environments, and how to deploy.

Once the switch is final, rotate every password and API key the old team had. It is not about bad intent. Leaked credentials are one of the most common ways in for attackers: Verizon's 2025 Data Breach Investigations Report found credential abuse was the initial access vector in 22% of breaches, and third-party involvement in breaches doubled to 30%. GitGuardian's State of Secrets Sprawl 2025 also found that 35% of private repositories they scanned contained at least one hardcoded secret, so assume your code may contain keys too.

What does a code audit look like?

Before you decide anything big, have the new team review what exists. A useful audit usually takes 1 to 3 weeks depending on size and covers:

• Can it run? Can the new team set it up and deploy it from scratch with what was handed over?
• Structure. Is the code organized in a way another developer can follow?
• Tests. Are there automated tests, and do they pass?
• Dependencies. Are libraries current, or years out of date? This is common: Black Duck's 2025 open source risk report found 90% of the commercial codebases it audited had open source components more than four years old, and 86% contained known vulnerabilities.
• Security. Hardcoded secrets, weak authentication, unprotected data.
• Data. Is the database design sound, and is there a working backup?
• Gaps. How far is the code from what you were promised?

The output should be a short written report in plain words, with a recommendation: continue, refactor parts, or rebuild.

Continue, refactor or rebuild?

Most of the time, the answer is not a full rebuild. Rebuilding throws away working parts and real lessons, and it costs months.

• Continue when the code is reasonable and the problems were mostly about process or communication.
• Refactor when the core works but certain parts are fragile. Fix those parts while still shipping features.
• Rebuild when the code cannot be run, has no clear structure, has serious security problems, or was built on a platform that cannot do what you need.

Be wary of any new developer who says "rebuild" before they have looked at the code. And be wary of one who says everything is fine without looking either.

If the audit shows deep problems, the next question is whether to rebuild or refactor.

What should a handover checklist include?

If your old developer is cooperative, ask for a handover session (recorded, ideally) and this checklist:

• Owner access to all code repositories
• Admin access to hosting, cloud, database and storage accounts
• Domain registrar and DNS access
• App store accounts transferred or access granted
• List of every third-party service, with account owner
• All credentials in a company-controlled password manager
• Setup and deploy instructions that a new developer has actually tested
• List of environments (development, staging, production) and how they differ
• Open bugs, unfinished features and known issues
• Any design files (Figma, Sketch) and brand assets
• A recent database backup, confirmed restorable
• Confirmation in writing that you own the code and IP, per your contract

Pay any undisputed invoices so the handover is not held hostage. If there is a dispute, keep it separate from access. Your contract matters a lot here, so check what it says about ownership before you start.

What should you expect from the new team?

Be realistic. The new developer is starting cold.

• The first 2 to 4 weeks go into the audit, setting up environments and fixing whatever blocks deploys. Feature work is slow.
• Estimates will be wider at first, because the code has surprises.
• Some "done" features will not be done. Plan for that in your budget.
• Things get faster once the new team owns the codebase and has tests in place.
• Weekly demos from day one, even small ones, so you can see progress instead of hearing about it.

Choose the new partner carefully. The same mistakes that led to this situation can repeat. Our guide on how to choose a software development partner covers what to ask, and our post on software maintenance costs after launch helps you budget for keeping the system healthy. A good partner should give you back hours each week, not take more of them.

Quick answers

Can a new developer take over someone else's code?

Yes, almost always. It takes some time to learn the code, and quality varies, but experienced developers take over existing projects regularly. Access and documentation matter more than who wrote it.

Do I own the code my developer wrote?

Usually, if your contract says so and you have paid. Check for a clause that assigns intellectual property to you on payment. If the contract is silent, talk to a lawyer before the relationship ends.

What if my old developer won't hand over access?

Start with a written request listing exactly what you need. If accounts are in your name, you can often regain access directly through the provider. If they are not, your contract and a lawyer are the next step.

How much does it cost to switch software developers?

Expect to pay for an audit and some ramp-up time before new features ship. The bigger cost is usually fixing what was left half-done. An audit gives you a real number instead of a guess.

How do you switch software development vendors without downtime?

Secure your accounts first, then run the two vendors in parallel for a short handover window rather than a hard cut-over. The new team audits the code and sets up its own deployment path while the old one keeps the lights on. Pick a quiet week for the switch, keep the old environment available for rollback for at least a few weeks, and agree in writing who is on call during the overlap.

Should I tell my current developer I am switching?

Yes, but only after you have secured access to your accounts. Be direct and professional, ask for a handover, and agree a final date.

Next step

If your project is stuck and you want an honest look at what you have, we can help. Book a free call, tell us where things stand, and we will send you a written recommendation within a few days.