What should my web developer hand over at launch?

Your new website goes live. You get a congratulations email, a link to the editor and maybe a password or two. A few months later you want to change a page, hire someone else or move hosting, and you find out the domain renews on your developer's card.

A good handover lets your business run, edit and move the website without its original developer. Here's what to ask for and how to check it.

This is general information, not legal advice. Ownership depends on your contract and local law. Check the agreement, and a qualified professional, before acting on a dispute.

Which accounts should be in your name?

Start with the accounts, because files are useless without them.

Your business should control the accounts it needs to keep the website running, with your developer invited through their own login. For managed services, agree access, billing and how you could move elsewhere. A shared password alone doesn't establish ownership: check who controls password resets and administrator access.

Ask for each of these, and confirm you can log in yourself.

Account	What it controls	What a proper handover looks like
Domain registrar	Your web address and its renewal	Registrant and login in your company's name
DNS (often Cloudflare or the registrar)	Where the address points, plus email records	Same account as the domain, or one you own
Hosting (Vercel, Netlify, a server)	Where the site runs	Project in your team, with your billing
Code repository (GitHub, GitLab)	The source code and its history	Repository in your account or organisation
Content editor or CMS	Text, images, blog posts	Your own admin login
Email sending (Resend, SendGrid, Postmark)	Form messages reaching your inbox	Account in your name, sending domain verified
Google Search Console and Analytics	Search data and visitor numbers	You as owner or administrator
Booking, payments, chat, newsletter tools	Everything the site connects to	Accounts in your name

The domain matters most. A public ICANN Lookup shows which registrar holds your domain, but personal details are usually hidden. The reliable check is logging into that registrar yourself and seeing your domain in your account.

For Search Console, Google says a property needs at least one verified owner, and that when you take over a site you can remove previous owners by removing their verification. In Google Analytics, adding or changing users requires the Administrator role, so make sure your business holds it.

What files and code should you receive?

The live website is the result. You also need the material it's made from.

• The source code, with its history. Prefer a repository on GitHub or GitLab in your account. A ZIP can contain editable source code, but downloading the published pages isn't the same thing. Ask for the source, dependency files and instructions needed to rebuild it.
• The design files. The Figma (or similar) file with the approved layouts, so a future designer works from the same pages.
• Brand assets. Logo files, colours, fonts and the images used on the site, in their original quality.
• A content export. Most content editors can export pages and posts. Ask how.

GitHub lets an admin transfer a repository, redirecting old repository links. Vercel lets a team owner transfer a project to another team without downtime. Check the platform's requirements before moving anything.

If an AI tool built the site, connect it to a code repository your business controls. Lovable can sync a project to GitHub. Its transfer and account-switching rules differ, so check the documented route before moving the repository. Connecting your own account from the start avoids that handover step.

What should the handover document say?

Accounts and files tell someone what exists. The handover document tells them how it works.

It doesn't need to be long. A clear page or two should cover:

1. Every outside service the site uses, what it does and who pays for it. Fonts, maps, forms, captcha, analytics, email, booking.
2. How to edit content, with the sections you can change yourself and the ones that need a developer.
3. How a change goes live: where the code is, how it's published and how long that takes.
4. Settings that live outside the code, such as the names of API keys and where they're stored. A new developer needs to know they exist.
5. Backups: what's backed up, where and how to restore it.
6. Known issues and anything left out of scope.
7. What happens after launch: the bug-fix period, who to contact and what counts as new work.

Our article on website maintenance costs goes further on that last point.

What can't be handed over?

Some parts of your website are licensed, not owned. Find out which before the developer moves on.

Fonts and photos often come with a licence tied to someone's account. Adobe, for example, says that when the subscription behind a web project ends, its web fonts stop being available on the sites using them, and the browser falls back to a default font. If the developer's subscription supplies your fonts, your site's look depends on their account.

Platforms stay where they are. A Shopify store account can be handed over, but the store itself can't be moved to another host; leaving the platform is a migration project.

The developer's own tools, such as paid plugins or code libraries licensed to them, may need new licences in your name.

Ask for a list of every licence the site relies on, who holds it and when it renews. Then move each one to your business or buy your own.

If you're planning a website and want the handover settled before work starts, we're happy to talk it through. With Aruno, you own the custom work once the project is paid in full, under the terms in your agreement, and anything we built that breaks in the first 30 days after launch is fixed free of charge. We'll agree which sections you can edit yourself before we build. Start with a free intro call, with nothing to sign, or reach us at hi@aruno.studio, on WhatsApp or on Telegram at @mihaipostelnicu.

Is it fine if your developer keeps access?

Often, yes. Access isn't the problem; ownership is.

A developer maintaining your site needs access. Invite them to your accounts, so you can remove their access when the work ends.

If the developer used their own accounts during the build, agree the transfer before launch.

How do you test the handover?

Run what we'd call the next-developer test: could a stranger take over tomorrow without calling the person who built it?

• You've logged into every account in the table above with your own credentials
• Password resets for those accounts go to an email address your business controls
• The domain shows your business as the registrant inside the registrar account, with your card on renewal
• The code repository is in your account, and its latest changes match the live site
• You've changed one sentence in the content editor and seen it on the live site
• A test enquiry from the contact form reached your inbox
• You have the design file, brand assets and the handover document
• You know every licence the site relies on and who holds it

Anything you can't tick goes back to the developer as a short, specific request. Doing this in the first week is much easier than months later, when the person who built it has moved on. If the form test fails, our guide to contact forms that don't send emails helps you find the gap, and a launch that only half-works is covered in why a site works in preview but not live.

Frequently asked questions

These answers cover common access and ownership questions at handover.

Do I own my website's code if I paid for it? It depends on your contract. Many agreements transfer ownership of the custom work once it's paid in full, while third-party parts stay under their own licences. Read the intellectual property section of yours, and ask the developer to confirm it in writing if it's unclear.

What if my developer won't hand over my domain? Ask in writing for the transfer to your own registrar account. Registrars give transfer codes to the domain's registered holder, so if the developer registered it in their name, you'll need their cooperation or legal advice.

Should my developer send passwords by email? Prefer invitations that let you create your own login. If a service needs a shared credential, use a secure password-sharing method and confirm that recovery goes to your business. Don't publish API keys or passwords in the handover document.

What should I ask for before signing a website contract? Ask who will own the domain, hosting and code accounts, when ownership transfers, what the handover includes and how long bugs are fixed after launch. Our guide to website costs helps you compare the rest of the quote.

Can I change developers after launch? Yes, if you hold the accounts and the code. A new developer will usually want to review the code before quoting changes, and a good handover document makes that review shorter.

The congratulations email shouldn't be the last thing you receive at launch. Ask for the accounts, files and notes, then run the next-developer test while everyone still remembers how the site was built.