What exactly should be handed over?
When an app goes live, the code is only one part of what the business needs to own. Make a list of everything the product depends on: source repositories, build instructions, hosting, domains, app store developer accounts and third-party services such as email delivery, payments or maps. Next to each item, write down who owns it and who has access today. Keep this list from the first day of app development.
This list often brings awkward surprises to light: a store account registered to a contractor’s personal email address, a domain renewed on someone’s private card, or a service key that only one developer knows. All of these are far easier to fix before launch than in the middle of an outage.
Decide how access will be transferred safely. Passwords and keys belong in a password manager or the hosting provider’s secrets store, never in a shared document, the repository or a project chat. Where the product stores customer data, include how that data can be exported and how the system is restored from a backup.
The test of a good handover is simple: could the owner, or another competent team, build, deploy and run the product with what they received? An archive of code without build steps, accounts and documentation does not pass that test.
Does the release work where real users will use it?
A build that passed every test in staging can still fail in production, because the settings are different, the permissions are real and a service key may simply be missing. After release, walk through the main user journey in the live environment yourself, on the devices and operating system versions you have promised to support, and with an ordinary user account, not an administrator’s.
Then check what happens when something goes wrong. Are errors reported somewhere the team checks? If backups are part of the service, has anyone restored one, and does the restored copy work? Can a faulty release be rolled back, and how long does that take? With store apps, a rollback usually means publishing a corrected version, so for risky updates it is worth releasing gradually to a share of users first.
Decide who receives alerts and what that person is allowed to do on their own: restart a service, switch off a feature or contact the hosting provider. Finally, record the known limitations and the acceptance results at launch. Otherwise your support staff will have to rediscover the scope of the product from customer complaints.
What should ongoing maintenance include?
Most disagreements after launch come down to one question: is this a defect, or is it new work? Settle it in advance by separating three kinds of task. Defect correction deals with behaviour that was accepted at launch and has stopped working. Compatibility work keeps the product running as operating systems, browsers, store requirements and third-party APIs change. New features are anything that goes beyond the accepted scope.
For each kind, write down how requests are submitted, how quickly the team responds, which hours support covers and how changes are estimated and approved. This is not bureaucracy: when a payment provider changes its API, both sides should already know whose job the update is.
Keep a running record of operating costs and dependencies, such as hosting, paid services, certificates and libraries, and name the person who watches for changes and renewals. Every product update should repeat the relevant acceptance cases and keep existing user data compatible. Maintenance is a continuing responsibility, and like any responsibility it needs a written scope.
Checklist: launch and support
- List the source code, accounts, hosting, domains and services, with an owner for each.
- Move passwords and keys into a secure store before handover.
- Test the main journeys in the live environment, including backup restoration and rollback where they are part of the service.
- Write down what support covers, how quickly it responds and how new work is approved.
- Keep an up-to-date record of known limitations, running costs and dependency updates.
Example: a handover the customer can use
The customer receives the repository under their own organisation’s account, build steps that another developer can follow and a release checklist. The store developer accounts and the hosting are registered to the company, and the team has named who watches monitoring and who checks the backups.
Some time after launch, two requests arrive. One asks for a new reporting screen, so it is estimated and approved as a separate change. The other reports that the order journey, accepted at launch, fails after an operating system update, so it follows the defect process. Because the boundaries were written down in advance, neither request turns into an argument.
