What should you receive when a software project is handed over?

Why is source code alone not enough?

A mobile app or web platform is the sum of dozens of accounts the code runs on. The store listing, domain, database, file storage, email delivery, push notifications and payments each live in a separate account. If you receive the code but those accounts stay in the developer’s name, you still need that person to ship an update, change billing or continue with another team.

The most common problem we see: the app is live, but under the agency’s own developer account. When the relationship ends, you may own the product on paper and still be unable to manage its store listing. That is why we open accounts in the client’s name from the start and hand over every credential together with the source code.

Which accounts must be yours for a mobile app?

• Apple Developer Program: 99 USD per year. For a company account, Apple asks for the company’s D-U-N-S number. It is free to obtain but can take days, so start it at the beginning of the project.
• Google Play Console: a one-time 25 USD. Organisation accounts also need a D-U-N-S number, and new personal accounts must run a closed test before production release.
• In App Store Connect and Play Console, the developer gets only the role they need. You remain the Account Holder.
• If there are in-app purchases, subscription products, tax and banking details are set up in your account, and the revenue is paid to you.

If the app already lives in someone else’s developer account, Apple and Google both offer app transfer. Users and reviews are kept, but both accounts must meet certain conditions. Starting in the right account means you never need it.

What happens if the Android signing key is lost?

Android apps are signed with a key, and every update must carry the same identity. With Google Play App Signing, the actual app signing key is held by Google and the developer keeps only an upload key. A lost upload key can be reset through Play Console. That is not a disaster, but it can mean several days without updates.

At handover, ask for the .jks or .keystore file, the key alias and both passwords. If Expo EAS manages credentials, the EAS account must sit in your organisation too. On iOS, certificates and provisioning profiles can be regenerated from the Apple account, which is why owning that account is what really matters.

Rather than emailing these files, share them through a password manager or an encrypted archive, with the password sent over a separate channel.

What should be handed over on the web and backend side?

• Domain: you must be the registrant. Under ICANN rules, a newly transferred .com cannot move to another registrar for 60 days, and most registrars apply the same 60-day lock to new registrations. Knowing this avoids last-minute surprises.
• DNS and CDN account (Cloudflare, for example), where the domain’s records live.
• Hosting or platform account: Vercel, Cloudflare, AWS, Google Cloud or a VPS provider.
• Database: Supabase, Firebase or managed PostgreSQL, with you as owner and backups switched on.
• File storage (S3, R2, Firebase Storage) and the transactional email service.
• Payments: iyzico, PayTR, Stripe or a bank’s virtual POS. The merchant agreement is already in your company’s name, and the API keys should be generated from your dashboard as well.
• Environment variables: a list of which key belongs to which service. Not the secret itself, but where it is generated.

How should the source code be delivered?

Instead of a zip file, ask for the code to be moved into a repository in your own GitHub or GitLab organisation, with its commit history. History is the most reliable way to understand why each change was made, and it makes the next team’s job much easier.

The repository should contain at least:

• A README that sets the project up from scratch: tool versions, install commands, running it locally.
• A file such as .env.example listing every variable name, without values.
• The database schema and migration files, so the database can be rebuilt from files rather than by hand.
• Release steps: how the store build is produced on mobile, and how the web app is deployed.

Secrets never having entered the repository is part of the handover too. If one did, rotate it. Deleting it from history is not enough.

Are design files and the admin panel part of the handover?

Yes. If the Figma file stays in the team’s personal account, you lose the design system the moment you want a new screen. Ask for the file to be moved into your Figma team, and for a list of font licences and image sources used.

The admin panel is part of the product, not an extra. At least one super-admin account must be yours, and you must be able to create and remove the other admin accounts. We do not use off-the-shelf panel templates; panel screens are designed and built for each product, so the panel’s code lives in the same repository and the same handover.

How should post-handover support be planned?

Handover is not the moment a product is finished. In the first weeks, real users surface cases that testing did not. Yearly iOS and Android releases, store policy changes and library updates create regular work too.

Two things should be separated. First, fixing defects within the delivered scope: we continue doing this after handover, and our clients can always reach us. Second, ongoing maintenance such as new features, store and OS compatibility and server monitoring, which is planned separately. Writing these as two clauses in the agreement prevents the later “is this a bug or a new request?” debate.

A short checklist for handover day

• Are you the Account Holder for Apple Developer and Google Play Console?
• Do you hold the Android upload key, alias and passwords, received over a secure channel?
• Do you have the owner role on the domain, DNS, hosting and database accounts?
• Were payment, email and notification keys generated from your dashboards?
• Is the code in a repository in your organisation, with its commit history?
• Are the README, .env.example, migrations and release steps in the repository?
• Is the Figma file in your team, with font and image licences listed?
• Do you hold a super-admin account in the admin panel?
• Are defect support and maintenance written as separate clauses in the agreement?

At AMG Software we open accounts in the client’s name from day one and hand products over against this list.