Why we hand over the domain, code and accounts
A website has a visible part and an invisible part. The visible part is what people see when they open the address: pages, type, images. The invisible part is everything that makes those pages exist and keep existing: the domain, the hosting, the code, the files, the accounts, the passwords and the order in which all of that was set up. Most conversations about a new site are about the visible…
A website consists of two parts: the visible part that users see and the invisible part that powers it. Most discussions focus on the visible part, but the invisible part—containing the domain, hosting, code, files, accounts, and passwords—is crucial in determining who truly owns a website. Owning a website means possessing a list of concrete elements, not just a feeling of control.
The domain name is the address of the website and the hardest to replace. Moving hosting or changing the address requires updating every link, card, profile, and search result. Registering the domain in your name, with login access, prevents loss of control over the site's identity.
Hosting and deployment details are important. Knowing where the site resides, how to access that account, and the associated costs ensures you can move the site without permission if needed. If the site is hosted under someone else's account without access or documentation, control becomes an issue.
The code, build configuration, images, and text are essential for future developers to maintain the site. If these files reside only within someone else's controlled environment, rebuilding becomes a challenge. Receiving the files or repository means having the ability to continue the work if ownership changes hands.
Websites generate numerous accounts, each serving specific purposes. A comprehensive map detailing these accounts, their functions, registration details, and access permissions is necessary for smooth operation. Without this map, managing the site becomes difficult.
Security measures, such as two-factor authentication, and recovery procedures for critical accounts are vital components of the deliverables. If you own an account but cannot recover it, the control is limited.
Lock-in often results from small choices, like registering the domain through the builder's account or deploying from a personal repository. These shortcuts may seem convenient initially but can create dependencies that hinder future changes. A healthy arrangement allows easy transition without being tied to a single provider.
Clients should receive the domain, hosting details, site files or repository, account map, security and recovery notes, content, media, search basics information, Search Console and analytics access, and a clear statement of post-delivery steps. Providing these elements empowers the client to maintain and manage the website independently after the project concludes.
Written by urgent.news from Dev.to's reporting — not their text. Machine-written — may contain errors; check the original before relying on it.