Español
English
Català
FrançaisThe website opens and the client has approved it. Something else still needs checking: whether they can keep it, pay for it, renew it and commission changes when you stop administering it. Delivering a URL does not automatically deliver the domain, accounts or files needed to publish another version.
An original developer question in Spanish describes exactly this situation: a static website with no API or backend, whose developer wants the client to control the domain rather than remain its operational owner. This guide proposes a documented handover procedure. It does not assume how the site was built or treat forum replies as provider instructions.
We will use an original MIT template pinned to a commit. It records responsibilities and checks; it is neither a contract nor an automatic panel feature. It does not demonstrate native Hostbrid transfers.
Record what you are handing over and what is excluded
Complete one row per service: domain, DNS, hosting, repository, email, forms and measurement. Add a server and database when present; mark “not applicable” where appropriate. Record a reference without secrets, the account holder, payment and renewal responsibility, available technical access and its removal procedure.
Before choosing a product, distinguish static files from a server process. Start with hosting for an AI-built website and the repository inventory. Include external dependencies even when there is no backend of your own.
An illustrative case: a carpenter’s static website
Imagine a website at ejemplo.invalid, a domain reserved for this example, with no API, authentication or forms. After checking the project, the server, database and customer payments rows can be marked “not applicable”. The domain, repository, hosting account, service payment and renewal still need responsible people. Client and technician would record the files to deliver and access to remove. They would then need to run the page, reload and image checks described below. This is an illustrative situation, not a real client or a tested handover.
Separate domain control from publication
Identify the registrar account, the registered holder and who receives notices and can recover access. If the client will be responsible, confirm these details and the registrar’s requirements with them. Pointing the domain at your server does not deliver the account.
Moving DNS, changing hosting and transferring a domain between registrars are different operations. Before changing name servers, inventory the records supporting the website and email. The guide to changing DNS without losing email covers that specific operation; it does not replace handing over the registrar account. Do not cancel the previous service until you have checked what still depends on it.
Use individual identities and describe actual permissions
The client should be able to sign in with their own identity and recover their account. If delegation is available, use a separate agency identity with the permissions actually provided. Do not exchange passwords or put tokens or private keys in the template.
Check who can view data, publish, change DNS, purchase or cancel, operation by operation. Do not infer these capabilities from labels such as “viewer” or “administrator”. If delegated access does not exist, record the limitation and agree on an alternative with the provider before relying on it for handover.
Hostbrid may be a candidate destination depending on your project’s architecture and published services and plans. Before purchasing, confirm the access conditions you need. This checklist does not demonstrate an invitation workflow, universal viewer permissions or automatic account transfers at Hostbrid; recording responsibilities and pending tasks does not require assuming those features.
Deliver files and check from the client’s context
Record the code revision, build instructions and files authorised for delivery. Keep the required lockfile and explain how to change text and images. Separate shareable configuration from secrets, and agree in writing on rights and conditions for the material; administering an account does not by itself determine its legal ownership.
Record each check in the template’s expected, observed, evidence and date columns. Test the home page, a direct internal URL, reloads, images and missing routes. Check that the expected page appears: HTTP200 can be a fallback home page. If there is a form, testing should reach an owned authorised destination, not third parties. A downloaded backup does not prove restoration; record what you have actually recovered in an isolated environment.
Close out payments, support and access removal
Record renewal dates, payment responsibility, notifications and external services that will remain active. Distinguish the website sale from subsequent maintenance and excluded tasks. The template does not establish legal obligations or guarantee you can withdraw unilaterally.
Agree on the material to deliver, who will handle a future move and how long the service will remain available during that transition. After confirming client access and continuity, the authorised person can remove agency identities and rotate relevant credentials through the appropriate service, following the agreed procedure. Do not act on third-party resources or production without specific authorisation. Check that removal does not delete the account or interrupt publication. Anything you cannot verify must remain pending, with a responsible person, rather than being marked “delivered”.