Changing development teams is common: a freelancer moves on, an agency relationship ends, an in-house developer leaves. The risk is not the change itself but doing things in the wrong order — adding features on top of something nobody fully understands yet. This is the order we recommend.
Signs it is time to change teams
- Releases slip repeatedly, or each release breaks something that used to work.
- Simple changes take far longer than they should, and nobody can explain why.
- You cannot get straight answers about the state of the code.
- The app no longer builds with current tools, or store updates have been rejected.
- Only one person understands the system, and they are not available.
None of these alone means the code is bad. Together, they mean you need an independent view.
Collect access before anything else
Before the previous team leaves — or as soon as possible if they already have — make sure your company holds:
- Source code in a repository your company owns, with full history.
- App Store and Google Play accounts, with your company as the account holder.
- Signing keys and certificates needed to publish updates. Losing an Android signing key can make it impossible to update an existing listing in the normal way.
- Servers, hosting and databases, including backups.
- Third-party services: payments, maps, push notifications, email, analytics, crash reporting.
- Domain names and DNS.
- Documentation, designs and credentials, transferred securely.
Make a list and tick each item off. This list is your insurance.
The code and architecture review
A new team should review the code before promising anything. A useful review answers:
- Does the app build and run from the repository as it stands?
- Which libraries, SDKs and OS versions are out of date, and how urgent is each?
- Where is the code fragile or hard to change, and why?
- Are there security problems — exposed keys, weak authentication, unprotected APIs?
- What does it cost to keep it, compared with rebuilding parts of it?
Ask for the findings in plain language with priorities, not as a list of everything a developer would do differently.
Stabilise before adding features
The first work after a takeover should make the app boring to release:
- A build that anyone on the team can produce.
- A release process that works for both stores and the server.
- Crash and error reporting, and the worst crashes fixed.
- Store requirements met, so updates are not rejected.
Only when releases are routine should new features start. Otherwise every feature inherits the instability.
Fix, refactor or rebuild: how to decide
Decide part by part, not for the whole app at once:
- Fix what works but has bugs.
- Refactor what works but is hard to change, when you will change it often.
- Rebuild what is broken at its foundation, or what blocks the product’s direction — and only once you understand what it does today.
A full rebuild is sometimes right, but it is rarely the cheapest way to keep users happy in the meantime.
Transferring store listings, back end and services
Moving accounts and services needs planning, because some transfers affect live users: store listing transfers, server migrations, changes to push notification or payment credentials. Schedule them, test them, and keep the old setup working until the new one is confirmed.
Ongoing maintenance and updates
After a takeover, set a rhythm for maintenance: OS and SDK updates each year, library updates, security fixes and monitoring. A small, regular budget for this prevents the next emergency.
Make sure you own everything next time
The best time to prepare for the next change of team is now. Keep accounts in your company’s name, code in your repositories, and ask for short handover notes as the work goes on. How we work explains what we hand over on our own projects.
If you have an app that needs a new team, tell us what exists today and what is going wrong. We start with the access list and a review, and explain what we find before agreeing next steps.