Who can take over your app? How to choose the next team

Your developer left, or your agency went quiet, and now someone else has to take over your app. Who can, and how do you choose the team? The one to trust asks for access to your code and accounts, and writes down what it finds, before it promises fixes, dates or a rebuild. This article gives you the options, the questions to ask and the warning signs. MobiStack Digital takes over, fixes and builds mobile apps and web platforms, so where we answer a question ourselves, we say how.

In short

• Choose the team by how it starts. The team to trust asks for access and writes an audit before it promises fixes, dates or a rebuild.
• Put the code, the store listings and the cloud accounts in your company’s name, whoever takes over. Both app stores can move an app to your own account.
• Ask who reads every change before it ships, and how you will see progress each week.
• Be wary of a fixed quote, a deadline or a rebuild offered before anyone has seen the code.

Who can take over an app that someone else built?

Any developer or team that can get access to the code and the accounts, build the app from a clean machine and release an update. That can be a developer you hire, a freelancer or a studio. The label matters less than whether they can show you how they would take the first steps.

Each option comes with one question to put to it:

• A developer you hire. They get to know your product day to day. Ask who reads their changes, and who covers when they are away.
• A freelancer. Good for a task with a clear edge. Ask who reviews the work and what happens to your accounts if the freelancer is no longer available.
• A studio. It can cover mobile, web, design and testing together. Ask who exactly will work on your app, and who reads their changes before they ship.
• The team that built it. It may still help. If it has gone quiet, ask once, in writing, for access to exactly what you need, as set out in what to do when your agency stops responding.

What does a takeover involve?

A takeover has four steps, in order. The new team gets access, then writes down what it found in an audit, then helps move the code, store listings and cloud accounts into your company’s name, and then fixes the problems that cost you customers first. The audit comes before any promise.

What the audit looks at, and what you receive at the end, is covered in Taking over an app from another developer. This article is about the step before it: choosing who does the work.

What should the new team ask you for first?

The code repository, the app store accounts, the cloud project that runs the app, the domain and email settings, and any keys, certificates and contracts. A team that asks for none of these is guessing, because it cannot see what it is taking over. A team that asks for all of them is already planning the move.

You may not be able to reach all of it, and that is a common starting point. Say so. Which of these accounts sit in someone else’s name is the first thing the audit records.

Both app stores can move an app to your own account, with its reviews and users. On the iPhone store, the account holder of the current account starts the transfer (opens in a new tab) and the account holder of the receiving account accepts it. On Android, the owner of the current developer account starts it and the target account owner approves it (opens in a new tab). Both start from whoever holds the app today, so ask for that early.

Which questions show a team can take over well?

Ask how it audits, who reads every change before it ships, how a release reaches your users, how you will see progress each week, and what it does when something cannot be recovered. Good answers are specific and name steps. Vague answers about experience tell you little.

Here is what a good answer sounds like to each:

• How do you start? “We get access, read the code and the accounts, and write down what we found before we plan any fix.”
• Who reads every change before it ships? A named role, and a process: tests run on every change, and a person reads it before it goes out.
• How does a release reach our users? The steps, in plain words, including who holds the store accounts and the signing keys.
• How will we see progress? Something you can open on your own phone or browser each week, not a status report alone.
• What if something cannot be recovered? A plain answer, such as publishing again from your own account, with what that costs you in reviews and installs.

Here is our own answer to the second one. Every change passes automated tests and automated code review, and one of our developers reads it before it ships. A change nobody read does not ship. Our developers build with AI and review every line, and how that works is written out. On a takeover, a new build to try every week starts once the code and accounts are in your name.

What are the warning signs?

A fixed quote, a deadline or a rebuild offered before anyone has seen the code. Also accounts kept in the team’s name, nobody named who reads the changes, and findings that are never written down. Any one of these is a reason to ask more questions before you sign.

Two of them deserve a closer look:

• A rebuild as the first answer. Sometimes a rebuild is right, but it is a conclusion, and a team cannot reach it before it has read the code. The questions that decide a rebuild are worth asking whoever you hire.
• Accounts kept in the team’s name. If the store listings, the cloud project or the repository sit in the team’s accounts, your app can only leave when they let it. Ask to open each one in your company’s name from the first day.

Does it matter where the team is?

Less than most owners expect. What matters is how much the team’s working hours overlap with yours, the languages you need to talk and write in, and whether you can sign a contract with a company. Ask for those three in writing, and ask where the people who will work on your app actually sit.

Our office is in Dubai, and our team works remotely in Beirut. Calls can be in Arabic, English or French. You can read more on our Dubai page.

What happens after you choose a team?

The written audit comes first. Then the fixes that cost you customers go first, with tests so they stay fixed. Once the code and accounts are in your name, you get a new build to try every week, so you see each change on your own phone as it lands.

You should be able to say, at any point, what was found, what is being fixed next and why. If the team cannot tell you, ask again before the next step.

Questions owners ask

What if the old developer will not hand over the code?

Read the contract’s ownership clause first, because it decides who owns the code. If the code is yours under the contract and nobody answers, a lawyer in your country can help you ask formally. In the meantime, an app that can never be transferred can be published again from your own account as a new listing, which starts without the old reviews.

Can a new team work on code it did not write?

Yes, and most teams do it regularly. The first job is to read the code and check that the app builds and releases, which is why the audit comes first. If the code is hard to change safely, the audit says where and why.

Will our users notice the change of team?

They should not. Moving an app between store accounts keeps its reviews, and users keep receiving updates. The first thing users should notice is the fixes.

Is it safer to hire one developer or a studio?

Either can work. Put the same questions to both: who reads each change before it ships, who covers when someone is away, and whose name the accounts are in.

What should we prepare before talking to a new team?

A link to the app, the accounts you know about, the contract and invoices if you have them, and the problems that worry you most. Nothing needs to be organised. We go through your product before the first call, so the time goes on what to check first.

Choosing the next team for your app?

Book a free 45-minute consultation. We go through your product before the call, then show you what we would check first and how we would plan the move into your name. You can also see what a product takeover includes.

Book a free consultation