Choose the delivery model before creating accounts
Some projects give the client control of accounts from the outset; others have the supplier manage infrastructure as part of the service. Make that choice explicit and understood by both sides. Establish who takes operational responsibility, which costs are included and how continuity works if the arrangement needs to change.
At the agency, we have worked with services whose infrastructure costs are included in the retainer. That avoids placing all the management of tools and separate invoices on the client. It is a service option that makes sense when responsibility for following the operation also clearly remains on our side.
That option should not mean leaving everything attached to the personal account of whoever built it. The organisation needs to administer the project and continue the work. It also needs to explain what happens if the client wants to move management to their own team or to another supplier later.
Imagine a request management application for a small maintenance company. The client may simply want the service to work without following every platform. Another client may have a technical team that requires control over access and billing. Delivery should respond to each client's actual situation and the responsibilities they want.
Clarify this when learning about a client before accepting a project. If the model is discussed only at the end, you may discover that the operation conflicts with the autonomy expected. Establishing the expectation early allows accounts and documentation to be prepared according to the service that was sold.
To prepare your next step, explore Building digital products with AI.
Map what keeps the application running
The handover should identify the code, hosting, data, domain and necessary integrations, showing who controls each part. Record the owners and dependencies between services. Access to the application may allow someone to use it without allowing them to administer it, recover information or publish a correction when that becomes necessary.
In the maintenance example, the team might receive requests through the application and notifications through another service. Delivering only the code leaves it unclear who manages sending and receives failure alerts. The map should explain the operational journey without making the recipient search through old conversations for each missing answer.
For each component, identify the responsible account or organisation, how to obtain access and the contact who resolves problems. Do not put passwords or keys in the handover document. Documentation should point to the secure process for managing credentials, keeping the explanation separate from the secrets needed to operate services.
Include recurring costs, distinguishing fixed charges from variable usage, using the project's actual data. If there is insufficient history to estimate an expense, acknowledge that limitation. The client needs to know which activity can change the cost and who will track its development while the application is in operation.
Provide control through individual access
The recipient should be able to enter accounts and perform assigned tasks using their own identity. Avoid solving handover by sharing a personal account used for other projects. Define appropriate permissions and confirm that recovering access does not depend exclusively on an individual outside the organisation that will use the application.
We have had to reorganise projects that were distributed across employees' personal accounts. Bringing the work into the company structure made responsibility clearer. The lesson is to prepare that structure before it becomes an obstacle to continuity, rather than waiting for someone to leave before discovering where every project is kept.
For the maintenance client, confirm who can manage users, consult data and request technical support. Those responsibilities may belong to different people. The client's commercial contact does not need every technical permission for the business to have control over the service it uses and the decisions that affect it.
When defining who approves each part of the project, add who authorises new expenses and changes to access. Autonomy requires someone able to decide and a procedure that enables the decision to be executed. A list of accounts without that responsibility leaves the original dependence unresolved in another form.
Verify the transition of each service
A transfer must follow each platform's conditions and be validated after completion. Changing ownership of a repository does not demonstrate that hosting, data and integrations were transferred as well. Follow a defined sequence and confirm operation using the recipient's access, with the configuration that will actually remain in their control.
GitHub supports repository transfers, but permission requirements and destination account conditions apply. That capability helps plan delivery; it does not remove the need to check what remains associated with the repository. Apply the same care in consulting current requirements for the other services actually used in the particular project.
Before carrying out the transition, identify what might interrupt work and prepare an appropriate recovery approach. Then verify relevant journeys: opening the application, consulting authorised information, recording a request and receiving the expected result. Validation should use the state that will actually be available to the client after the handover.
Review access that is no longer required without removing it before continuity is confirmed. If you remain responsible for maintenance, document that need and its scope. Handover becomes clearer when access reflects the current service instead of accumulating every person who was involved at some point during the build.
Close with evidence that work can continue
Handover is demonstrated when recipients can use and administer their responsibilities and know how to obtain help for the rest. Ask them to perform representative tasks with their own access. Record results, outstanding items and their owners instead of closing the work merely because invitations to the relevant accounts were sent.
For the maintenance application, this might include creating a team user, locating a request and identifying where to report a failure. If the client will manage the technology, add verification of the agreed update and recovery process. The demonstration's scope should match the responsibility the client is actually receiving.
This approach also helps rethink services when AI reduces execution work. Value includes making the result usable and sustainable for the client, with clear responsibility for what follows. Building quickly does not eliminate the work of preparing an understandable handover and an operation that has someone accountable for its continuity.
Finish with a short record of what was delivered, where documentation is kept, which costs are known and how a future management change works. If a dependency remains with you, explain it and attach a concrete commitment. The client should be able to assess continuity without relying on the builder's memory.