Practice ·
Website handover begins before the final commit
Website handover is often imagined as a final email containing passwords and a code archive. Access alone does not make the owner independent. A complete handover begins earlier: the domain and operational services belong to the client, deployment can be repeated, the previous version can be restored, and another specialist can understand the project without the original maker explaining it from memory.
Separate ownership from execution
A supplier may configure the domain, hosting, analytics and email services, but the client should own the primary accounts. Otherwise a completed website remains dependent on someone else's card, phone number, email address or personal account.
Create an ownership map early: who controls the domain, where the website runs, who pays for services, which address receives notices and who may add or remove participants. Every external service needs a responsible person inside the business.
The maker may retain access during support. That access should be a separate role that the owner can revoke rather than the only key to the project.
Hand over managed access rather than a password
Passwords should not be collected in a document or sent through a message. Most services can invite a participant, assign a role and enable additional protection. Where a shared secret is unavoidable, transfer it through a password manager and identify its owner.
Before completion, check access from a clean client profile. The client should see the required projects, invoices, domains and settings, while the maker retains only what their work needs. This test reveals dependencies the author of the project may no longer notice.
Integration keys require a separate record. Production secrets must not live in source code, conversation history or a public client application. The owner needs a way to replace them without rebuilding the entire system by hand.
The code must be able to become a website again
An archive of the latest version does not explain how to produce a working result. The project needs a repository, fixed dependencies, build commands, environment variables and a description of the hosting environment. A new specialist should be able to repeat a release from the instructions.
The test is simple: start from a clean copy, build the project and deploy it to a test environment. If this requires an undocumented step remembered by the original author, handover is not complete.
Preserve the route back as well. A known working release, data backup and recovery procedure protect the owner from a failed update. Rollback is part of the product rather than a technical luxury.
Content and data have their own route
The owner needs to know how to change copy, a price, an image or an article and when the change becomes visible. If every correction requires a developer, this should be an intentional property of the project rather than a surprise after launch.
Where forms exist, follow an enquiry from the page to its recipient. Where is it stored? Who receives the notice? How is a delivery failure detected? How can personal data be removed on request? These answers connect the interface to the company's real work.
Analytics should also be handed over as a system rather than an inserted counter. The business needs access, a list of measured actions and an understanding of which decisions the data can support.
Documentation describes decisions and actions
Useful documentation is short and concrete. It covers the project structure, external services, deployment, content updates, backup, recovery and support contacts. Screenshots help where an interface is hard to find; the logic of the action matters more.
Record constraints and key decisions separately. Why does the form use this service? Why are some pages built in advance? What cannot change without renewed testing? This information preserves the Concept and reduces the risk of breaking an important relationship by accident.
Test documentation through action. The client or a new participant performs one normal operation from the instructions. Their questions reveal what is missing better than a long final call.
Acceptance and handover answer different questions
Acceptance confirms that the website performs the agreed journeys and meets its criteria. Handover confirms that the owner can manage the working result. The stages are connected, but one does not replace the other.
Before handover, close a list of known constraints, open work and each party's obligations. What belongs to completion? What moves to the next release? How long is the warranty period? How are new changes commissioned? Clear boundaries protect the relationship after launch.
The final call becomes a readiness check rather than an attempt to explain the whole project in an hour. Access and instructions already exist; participants walk through the essential actions and record questions.
Support begins with independence
A good handover does not prevent further work. It lets the client choose it knowingly. The owner may continue with the same maker, invite another specialist or perform some operations independently.
Dependency can be disguised as support when only one person knows how to release the website, renew the domain or recover data. That relationship makes every change uncertain and slows the development of the product.
Within the Method, I design handover together with the website. Ownership, repeatable deployment, recovery and documentation become part of the system before the end. Launch then completes a stage without locking the product inside its author's memory.
Start with the website's purpose
If you are planning a website or rethinking one, we can begin with its role in your business, its structure and the visitor's path to an enquiry.