An app developer handover should establish who owns the code and accounts, how the app is built and released, which services it depends on and what issues remain unresolved. The new team needs enough evidence to assess the app before committing to ongoing support.
In this guide
If your original developer has moved on, you do not need to understand every technical detail before asking for help. You do need to identify who can provide the source files, permissions and knowledge the next team will need.
Start with a handover inventory
Ask the outgoing developer or agency to help complete a record of the following items. Treat anything missing as a question to resolve, rather than assuming it will be easy to recreate.
| Handover item | What the new team needs to understand |
|---|---|
| Source code | Repository location, relevant branches and the version used for the live app |
| Build instructions | Required tools, versions, configuration and how to produce a test build |
| Store access | Who owns the accounts and who can grant appropriate release permissions |
| Connected services | Hosting, authentication, payments, notifications and other dependencies |
| Test setup | Safe test accounts, sample data and supported devices |
| Known issues | Reproduction steps, previous investigations and unresolved limitations |
| Release history | Recent changes, approvals and anything that went wrong |
The inventory is a record of what exists. It is not a place to paste passwords, private keys or customer information.
Keep business ownership clear
Your maintenance provider needs appropriate access to do the work, but the business should understand which accounts it controls and who can manage permissions. Agree the access process directly with the relevant account owner.
A public App Store listing is useful context; it does not replace source-code access. Similarly, a collection of screenshots may explain the interface without explaining how to build or update it.
If ownership is disputed or someone cannot authorise access, clarify that before promising a takeover date. A maintenance engagement cannot resolve missing ownership rights simply by starting a monthly payment.
Ask for a build attempt, not an assumption
One of the most useful early checks is whether the receiving team can attempt a build using the supplied materials. A failure can reveal missing configuration, unavailable dependencies or undocumented steps.
The output should explain what happened and what is needed next. “Build blocked by missing signing configuration” is more actionable than “the code looks fine”. A successful build is helpful evidence, but it does not prove that every workflow works correctly.
For apps with separate iOS and Android codebases, establish the position for each. Do not assume that because one platform can be built, the other can also be released.
Transfer the reasons behind previous decisions
Documentation should explain more than file locations. Ask why a particular service was chosen, which workflows have unusual rules and where previous fixes caused problems.
For example, a booking app might prevent changes after a certain status. The new team needs to know whether that behaviour is a defect or a deliberate business rule. Without that context, a requested “fix” could remove something the operation relies on.
Arrange a focused handover conversation around the inventory and unresolved questions. Record decisions afterwards so the knowledge does not depend on remembering a call.
Separate takeover work from routine maintenance
Once the app’s condition is clearer, divide the work into three groups: ready for ongoing care, requiring a contained repair, and needing a separate recovery or development project.
Afiniti Global’s standard baseline assessment covers one mobile product with up to two mobile codebases, subject to eligibility and accessible source and store accounts. It includes an access and dependency inventory, a build attempt for each included codebase, available crash and store-notice review, and written priorities with a care recommendation.
It is an assessment, not a repair package. Missing-source recovery, major catch-up work and specialist assessments need separate scope. You can review the current assessment and care process before deciding whether to proceed.
Common handover questions
Can Afiniti Global maintain an app built by another developer?
You can enquire about an existing app built elsewhere. Acceptance depends on its technology, condition, access and release setup. Share the public app link and explain the handover position first.
What if I do not know the app’s framework?
Start with what you know: where the app is listed, who built it and who has the source. The technical details can follow during the fit discussion and agreed assessment.
Should I cancel the old arrangement immediately?
Plan the transition around confirmed responsibilities and access. Where possible, resolve handover questions while the outgoing team is still available, and make clear when each provider’s responsibilities end or begin.
Ready to organise your handover? Ask Afiniti Global to review your app’s fit for care. The initial enquiry is free and does not authorise paid work.