Ownership and access
The domain, the payment account and the cloud accounts are the client's; handover is a transfer of access, not a negotiation.
The question worth asking any vendor before work begins is what happens to the business if the relationship ends badly. Where the domain is registered, whose card the hosting bills to, and who is able to revoke whose access are the entire answer — and each is settled at the start or fought over later.
The client's domain is registered in the client's name, on the client's own account. A domain held by a vendor is the single most effective piece of leverage in the industry, and the fact that it is rarely used that way is not a reason to accept the arrangement.
The client's payment accounts are the client's own. The firm never becomes the merchant of record and never holds client funds, which is a policy, not a technical limitation and is published because it is the kind of question a business should ask and frequently does not.
Cloud and platform accounts are held by the client wherever it is practical, with the firm granted access to them, rather than the reverse. Where operational infrastructure genuinely sits on the firm's side, that is named explicitly, not left for anybody to discover during a handover.
Source code is delivered in a form the client owns, with its full history, not a snapshot. A full history is what makes it possible to establish when something changed and why, and a flattened handover discards precisely the record that has value later.
Access is granted per person instead of through a shared login. A shared account cannot be audited, cannot be revoked for one individual, and turns every departure into a password rotation across every system it touched.
Access is removed when it stops being needed, on a schedule instead of on recollection. Most excess access in a small business is not granted deliberately; it accumulates because nobody ever revisits it after a project ends.
Handover is treated as a deliverable with a checklist, not an event. What transfers, who receives it, what the firm retains and for how long, and confirmation that the client can build and release without help — the last of which is the only real test of whether the handover worked.
Nothing here requires trusting the arrangement to hold. It is checkable by the client at any point: look at the domain registration, look at whose name is on the billing, look at who owns the code. An ownership policy that cannot be verified is a sentiment.
What this does not cover.
- Holding a client's domain, payment account, or cloud account in the firm's name.
- Shared logins in place of per-person access.
- Handing over a snapshot of the code, not the repository and its history.
Managed Services & Infrastructure
Releasing changes
The commit that was built is verified by its identifier, and the release is verified against the live address instead of against a build status.
Backup and recovery
A backup nobody has restored is a belief; recovery time is measured by performing it, not estimated from the size of the file.
Environments
A non-production environment earns its cost by being wrong in the same ways production is.
Monitoring
Watching the things a business would actually notice losing, rather than the things that are easy to graph.
Keeping software current
Few enough third-party components that keeping them current stays possible three years after launch.
Coverage and response
Stated hours, not implied availability, because a commitment is only worth what somebody can plan around.