A Monday morning that needs to keep moving.
A customer cannot sign in. Your main contact is on holiday. A launch screenshot cannot help them; a clear route can. Who receives the report, who may check access and how can the customer continue meanwhile? This example shows what needs deciding before launch.
Keep accounts within your control.
Record who administers and pays for the domain, hosting, database and other providers. Agree roles and a recovery route instead of collecting passwords by email. Source code, usage rights, third-party licences and data exports are separate questions. Ask for each to be explained in the proposal.
A backup needs a working way back.
Which information must be available after a failure? How much interruption is acceptable? Use those answers to agree backups, responsibilities and a recovery test. Having a backup file does not by itself prove that recovery works.
Maintenance is not every new idea.
Separate provider fees, agreed maintenance, defect handling and new features. Make availability, response times and approvals explicit in the engagement. A handover package does not imply unlimited support or an automatic round-the-clock service.
Make the handover practical.
Within the agreed scope, we document systems, responsibilities, access, checks and open questions together. A responsible person walks through the important user task and tries the help route. What already works stays distinct from what still needs agreement.
Ask every provider these questions.
Can my team administer the accounts? What do we receive when the engagement ends? Who helps during an outage? How are changes checked and reversed? Ask for an explanation using your actual workflow rather than accepting a blanket “everything included”.
Not every app needs its own operations team.
A standard platform provider handles part of the operation. Configuration, user support, data and responsibilities still need agreement. Compare those tasks with custom development before choosing more technology.