Answer in brief
A website handover comes down to five items: the domain, the hosting account, the repository, an owner login to the admin panel, and the environment variables with their values. Here is how to verify each one before the final payment.
What you receive at handover: the short answer
At handover you receive five things: control of the domain, an account on the hosting platform, the repository holding the source code, an owner-level login to the admin panel, and the list of environment variables with a note on what each one does. Everything else is documentation wrapped around those five.
A website is a running system rather than a file. It has an address people find it by, a place where it executes, code it is built from, a panel where content is edited, and settings that connect it to outside services.
Miss one of the five and you own a site you can look at but cannot change. That is a commercial position, not a technical footnote: this list decides whether you can change supplier without paying again for work already done.
What follows takes each item in turn — what it looks like, what to verify before you sign off, and how handover sits inside the VITON13 packages, where scope and timelines are named up front.
The domain: who controls the registrar account
A domain lives inside an account at a registrar. Ownership rests on two things: who signs in to that account, and whose contact details sit in the domain's registrant fields.
The arrangement that works is a domain registered to your company, with the developer given delegated access or rights over the DNS records. The one that does not is a domain registered to the developer to spare you the paperwork.
Verify it yourself: sign in to the registrar with your own credentials, confirm the registrant email is an address your company controls, check that auto-renewal is switched on, and open the DNS records to see that they are editable.
A domain is also a recurring payment. Renewal is charged to whoever holds the account, so access and responsibility for the renewal date and the card on file travel together.
Hosting and the platform the site actually runs on
Hosting is where the built site is served from: a virtual server, a managed platform, a container environment. What matters at handover is the account, the plan it sits on, and the payment method attached to it.
Ask for the provider, the project name, the region, and your permission level. Owner or administrator rights are the target; a guest link that only shows logs is not access, it is a view.
DNS belongs in the same conversation: which records point the domain at the hosting, where the mail records live, how the certificate is issued and renewed. A plain text file listing those records is a fair deliverable.
Write down the failure path as well: which log to open, how to roll back to the previous deploy, who holds the right to do it. This is not a promise that nothing breaks, it is a documented route for when something does.
The repository: sources, not a folder of files
A repository is the code together with its history of changes. An archive named site-final.zip is not the source: it has no branches, no history, and no link between a change and the reason it was made.
What you want is the repository under your own organisation or account, with the owner role attached to you. The developer stays on as a collaborator while the work continues and loses access when it stops.
Inside, the things worth checking are a readable commit history, a build instruction someone else can follow, a dependency list with pinned versions, and no keys or passwords committed into the code.
The test runs quickly. Another developer clones the repository, follows the README, and ends up with a working local copy. If it does not start, the handover is not finished yet.
The admin panel: roles, owner rights and where content lives
Where a CMS or a custom panel exists, you need an owner account rather than an editor one. An owner creates and revokes users; an editor only changes text and images.
Ask for a list of every account that exists in the system, with its role attached. Accounts nobody needs are revoked as part of acceptance, not left for a tidy-up that never gets scheduled.
Then establish where the content physically sits: the database, uploaded files, the media store. And how a copy is taken — a manual export, an automated backup, and the place those copies are kept.
It helps to record which panel fields reach public pages: headings, metadata, redirects. An editor who knows the boundary of a field is an editor who does not break a layout with one oversized image.
Environment variables: the settings a build will not start without
Environment variables are the keys and addresses through which a site talks to outside services — the database, mail delivery, payments, analytics, file storage. They are not kept in the code; they are set on the platform.
Handover needs both halves: a list of the variables with a line explaining what each is for, and the values themselves, delivered through whatever your company already uses to hold secrets, such as a corporate password manager.
A list with no values leaves you with a build that refuses to start. Values with no list leave you with a pile of strings that nobody can interpret six months later.
Some of those keys belong to third-party accounts — a payment provider, a mail service. Those accounts have to be in your name as well, or a routine key rotation on their side takes your site offline.
Build and deploy: how sources turn into a running site
Between the repository and the published site sits a build: the commands that turn sources into what the server hands to a browser. That process should be written down and reproducible on another machine.
The minimum is a runtime version, the command that installs dependencies, the command that builds, and the command that runs. Better is the same steps in a continuous integration file, so the build does not depend on one laptop.
Deployment is documented separately: which branch reaches production, what happens automatically, what is done by hand, who is allowed to cut a release, and what a rollback looks like.
The value here is repeatability rather than elegance. A build that only succeeds on its author's machine is a hidden dependency on that author dressed up as a technical arrangement.
Third-party services: analytics, mail, payments, maps
A site rarely stands alone. An analytics property, transactional mail, form handling, payments, maps, a chat widget — each has an account behind it, a key, and somebody whose card is being charged.
Build a four-column table: service, account, owner, where the key is stored. That sheet saves time on the day one of those services has to be replaced, renegotiated or switched off.
Payments are stricter. The merchant account belongs to the legal entity receiving the money, and it cannot be parked with a developer as a technical detail. Payment licensing sits outside the Product Build scope.
Analytics deserves its own check: confirm that the data lands in your property and that administrator rights are yours. Otherwise a change of supplier costs you the history you were going to measure against.
Documentation: short, and not optional
Handover documentation is not a hundred-page manual. It is a README in the repository plus one page of runbook: what the site is made of, where it runs, how to build it, how to deploy it, and who to call.
Add a list of what was not done and why — deferred work, known limits, trade-offs that were accepted deliberately. That list is more honest than silence and saves the next supplier from rediscovering every decision.
Record the material your performance checks were based on. The Performance section of MDN Web Docs sets out loading metrics and browser behaviour, and pointing at it holds up better than a verbal understanding of the word fast.
Accessibility works the same way. The W3C quick reference for WCAG 2.2 lists success criteria in a form you can check against. If checks were run, note the conformance level and the pages they covered.
Why a handover without access means starting from zero
With no access, the next supplier never sees the sources and rebuilds from what a browser reveals. Layout can be reproduced; logic, integrations and panel configuration cannot be read from the outside.
Their hours then go into recreating the state you already have rather than improving it. You pay a second time for a site that is sitting on your domain and working.
The exposure is not only financial. Without the registrar account a domain can lapse quietly; without hosting access a site cannot be brought back after an outage; without the variable list a routine key rotation becomes downtime.
A handover with access turns the site into an asset the company owns. Without it, the site stays a piece of the developer's infrastructure that you rent on terms nobody ever wrote down.
How handover sits inside the VITON13 packages
Site Fix Pack is $70 and runs 1-2 working days: up to five agreed fixes, a mobile and desktop check, and a before/after list at handover, with 1 round of revisions. New pages, redesign and migrations are not included.
Launch Site is $380 over 3-5 working days: a responsive build, core CMS or data wiring, and deployment setup, with 2 rounds before launch. Content and translations are supplied by the client — we do not write them.
Product Build is $880 over 2-3 weeks: feature delivery, state and route logic, testing and hardening, with 2 rounds per delivered feature. Native mobile apps and payment licensing sit outside that scope.
Ongoing Dev Support is $290/mo for priority updates, a weekly release rhythm and technical maintenance; it runs on a monthly cycle with 30 days notice to stop, the volume of work is agreed at the start of each cycle, and a new build or redesign is scoped separately. Launch Site Express is $520 over 2 working days: the Launch Site scope in a priority queue with daily builds, a launch checklist and a handover call, with 1 round after the first full build, while content, photography and ongoing support are not included.
What to do before you sign off
Run the checks before the final payment rather than after it. Ask for the accesses, sign in from your own device with your own credentials, and confirm you can reach settings and not only the public pages.
Then ask for a build from a clean clone of the repository and deploy it to a test environment. That is how the variable list gets verified: if one is missing, the build itself will say so.
Move the list into the contract: domain, hosting, repository, admin panel, environment variables, third-party accounts, documentation. A clause can be enforced; a shared understanding that everything will be handed over cannot.
Scope, timelines and the number of revision rounds for each package are set out on the VITON13 development service page. Starting from that list makes the handover conversation a set of checkable items rather than a set of assurances.
Practical checklist
- Sign in to the registrar with your own credentials and check the registrant contact and auto-renewal.
- Take owner or administrator rights on the hosting account and request the DNS record map.
- Move the repository under your account and confirm it builds from a clean clone.
- Request the list of admin accounts with roles and revoke the unneeded ones during acceptance.
- Collect the environment variables with their values and store them in your corporate password manager.
- Write the list of transferred accesses and documentation into the contract before the final payment.
Questions and answers
What exactly should transfer to the client at the end of a project?
The domain, the hosting account, the repository holding the source code, an owner login to the admin panel, and the environment variables with their values. Alongside those come a list of third-party accounts and short documentation covering build and deploy.
What does the development work cost, and what is handed over with it?
Site Fix Pack is $70 over 1-2 working days: up to five agreed fixes with a mobile and desktop check and a before/after list at handover, with 1 round of revisions. Launch Site is $380 over 3-5 working days: a responsive build, core CMS or data wiring and deployment setup, with 2 rounds before launch.
Can the domain stay registered to the developer?
Technically it can, but then the renewal date and the rights over DNS records sit outside your control. Register the domain to your own company and give the developer delegated access instead.
Is a folder of files enough instead of a repository?
No. An archive carries no change history, no branches and no link between a change and the task behind it, so the next developer works blind. You need the repository under your account with the owner role.
Is a list of environment variable names enough without the values?
No: without values the build will not start, and values without an explanation cannot be interpreted six months later. Hand over the list with the purpose of each variable together with the values through your password manager.