Topics: Custom software & SaaS
Want this done for your business? Get a fixed quote or book a free 30-minute call.
Quick answer: First work out whether the problem is the vendor or the scope, because unclear scope follows you to the next team. If you do switch, secure admin access to code, hosting, domains and app stores before giving notice, check when IP transfers under your contract, and pay for an independent audit before deciding whether to salvage, refactor or restart.
Few things are more stressful for a business owner than a software project that's late, over budget and getting vaguer every week. The temptation is to fire the developer and start fresh. Sometimes that's right. But a rushed switch can leave you without your code, without your servers and paying a second team to rediscover what the first one knew. This is the sequence we'd follow, in order.
Should you switch developers, or fix the relationship first?
Diagnose before you decide: missed deadlines caused by unclear scope get fixed by re-scoping, not by changing vendors. A new team inherits the same fuzzy requirements and will miss the same deadlines.
| Symptom | Likely cause | Try first |
|---|---|---|
| Deadlines slip, but each demo shows real progress | Scope grew or was never pinned down | Re-scope, re-prioritise and re-baseline the timeline |
| Constant surprises about what "done" means | No written acceptance criteria | Agree criteria per feature before more work starts |
| Demos are rare, or always "next week" | Weak delivery or overstretched team | Ask for weekly demos and named staff; switch if it doesn't change |
| Features break each other every release | Poor quality practices, no testing | Get an independent code review |
| Developer won't share code or access | Leverage over unpaid invoices, or a deeper problem | Secure access now (see the next section) |
| Key developer left and nobody understands the code | Single point of failure | An audit decides whether it's recoverable |
If the first two rows describe you, a candid conversation and a written re-plan may save the relationship and months of handover. If the last four describe you, start preparing to switch, quietly.
What should you secure before telling the current team?
Admin access to everything, plus fresh backups, held in accounts in your business's name. Do this before any conversation about ending the contract.
Checklist:
- Code repository: you're an owner or admin on GitHub, GitLab or Bitbucket, and the full history is there, not just a zip file
- Hosting and cloud: owner access to AWS, Google Cloud, Azure, Vercel or the hosting panel, with billing in your name
- Domains and DNS: registrar and DNS logins in your name
- App stores: your business owns the Apple Developer and Google Play accounts, or you have admin roles on them
- Databases: a fresh backup you can access independently, plus the latest file storage
- Third-party services: email sending, payments, maps, SMS, analytics and error tracking, with API keys documented
- Design files and documents: Figma, specifications, test accounts and credentials stored in a password manager you control
If some of these are in the developer's name, ask for transfers as a routine housekeeping step while relations are still workable. Our software handover checklist lists everything a complete handover should include.
What does your contract say about termination and IP?
Check three things: how either side can end the contract, what you owe on exit, and when ownership of the code passes to you. Our guide to IP and source code ownership covers the background.
Read the contract for:
- Termination clauses: notice period, termination for convenience versus for breach, and any fees
- Unpaid invoices and milestones: what's genuinely owed for work delivered
- IP transfer: many contracts transfer ownership only on full payment, sometimes only for paid milestones
- Third-party and pre-existing code: libraries or frameworks the agency reuses across clients, usually licensed rather than transferred
- Handover obligations: whether the developer must provide documentation, credentials and reasonable transition support
In India, Australia, the UK and the USA, copyright in code written by an outside contractor generally stays with the contractor unless the contract assigns it in writing, so a missing or vague IP clause matters. If the stakes are high or the relationship is hostile, get a lawyer to read the contract before you act. This article isn't legal advice.
How should a new team audit inherited code?
Commission a paid takeover audit, scoped and fixed in advance, before agreeing to continue the build. An audit sized in days, not weeks, is usually enough to make a sound decision.
A useful audit covers:
- Can it be built and deployed? The new team gets the code running from the repository, on their machines and in a fresh environment.
- Code quality and structure: consistency, readability, obvious shortcuts, and whether the framework versions are still supported.
- Tests: whether automated tests exist, run and pass.
- Security: authentication, permissions, secrets in code, dependency vulnerabilities and data protection.
- Hidden dependencies: services, scripts or servers that only exist on the old developer's machine or account.
- Feature reality check: what's actually complete versus what's shown in demos.
- Data: database structure, migrations and whether production data is sound.
Ask for a written report with findings ranked by severity and an estimate for each option. When you choose the new team, our list of questions to ask a new development company helps you test them properly.
Salvage, refactor or restart: how do you decide?
Decide from the audit's evidence, not from the new vendor's preference. Some teams prefer restarting because they'd rather work in their own code; others prefer salvaging to win the job quickly.
| Option | Choose it when | Watch for |
|---|---|---|
| Salvage and continue | Code is reasonable, deploys cleanly and mostly matches the spec | Hidden quality issues surfacing later |
| Refactor progressively | Core structure is sound but parts are messy or untested | Refactoring scope creeping into a rewrite |
| Rebuild specific modules | One area, such as payments or permissions, is badly built | Interfaces between old and new parts |
| Restart | Code can't be deployed, is insecure at its core, or uses an unsuitable technology | Repeating the original scoping mistakes |
Even a restart rarely starts from zero: designs, specifications, test data and lessons learned all carry over. Our guide to deciding whether to rebuild, refactor or replace older systems applies the same thinking at a larger scale.
How do you run the transition without breaking production?
Plan an overlap, freeze new features, and re-baseline scope, timeline and budget before the new team writes new code.
- Agree an exit date with the outgoing team, with a short paid overlap for questions and knowledge transfer if they'll cooperate.
- Freeze new features during the handover. Only critical fixes go to production.
- Move deployments to pipelines the new team controls, and test a full deployment before the old team leaves.
- Rotate every credential and API key once access has been transferred.
- Re-baseline the plan: a fresh scope, timeline and budget built from the audit, with milestones you can verify.
- Restart with a small, visible win so both you and the new team see the process working.
If live users depend on the system, add monitoring and a rollback plan before the first new release. Tell key customers or staff about the change only once the new team has deployed successfully at least once; announcing a switch before you can ship a fix invites awkward questions you can't yet answer.
How do you avoid ending up here again?
Build ownership and visibility into the contract from day one. Most painful switches trace back to missing access and infrequent demos.
- Code lives in a repository your business owns from the first commit
- Hosting, domains and app store accounts are in your name
- Fortnightly demos of working software, not slide updates
- Written acceptance criteria for each milestone
- A handover clause covering documentation, credentials and transition support
- Payment tied to delivered, demonstrable milestones
Our guide to red flags when hiring an agency covers the warning signs to spot before you sign next time.
Frequently asked questions
Can I take my code to a new developer?
Usually, if the contract transfers IP to you and you've paid what's owed under it. Check the IP clause, secure access to the repository and hosting, and confirm whether any reused components are licensed rather than owned.
Do I have to pay the old agency before I get the code?
Often, yes, for work genuinely delivered, because many contracts tie the IP transfer to payment. If you dispute the quality or completeness of the work, document it and take legal advice rather than simply withholding payment.
How long does a developer transition take?
Gathering access and running an audit usually takes from a few days to a few weeks, depending on the size of the system and how cooperative the outgoing team is. Getting back to a steady delivery pace after that depends on what the audit finds.
Should the new team rewrite everything?
Not by default. Rewrite only when the audit shows the code can't be deployed reliably, is fundamentally insecure or is built on unsuitable technology. Otherwise salvaging or refactoring is usually faster and cheaper.
What if the old developer will not hand over access?
Start with a written request that cites the contract's handover and IP clauses. Recover what you can directly: domain registrars, cloud providers and app stores have account recovery processes for verified business owners. If that fails, take legal advice promptly.
Get an independent view of your project
If your project is stuck, a fresh pair of eyes on the code and the contract often clarifies the next move within days. You can book a project review call to talk through where things stand, or send us the details and we'll propose a fixed-price audit, usually within one business day.