Why a Freelance Web Developer Handoff Goes Wrong

A business owner pays a freelance developer to build a website, the site launches, everyone is happy, and then six months later something needs changing and nobody can log in. This is one of the most common and most avoidable failures in small business web projects, and it almost never happens because the developer did bad work. It happens because the handoff itself was never properly defined.

Key Takeaways

A finished website and a properly handed-off website are not the same thing; the second requires documented access, credentials and ownership of every account involved.
Who owns the domain, hosting account and code repository should be settled in writing before the project starts, not assumed afterwards.
Verbal promises to “send everything over” at the end of a project routinely fail once the developer has moved on to other work.
UK intellectual property law generally gives copyright in commissioned work to the freelancer, not the client, unless the contract states otherwise, which makes clear terms essential.
A short handoff checklist covering logins, documentation and a working final site check protects a business regardless of how good the working relationship was.

The pattern is familiar enough to have its own shorthand in web development circles: a project can be technically excellent and still leave the client stranded, because excellence in the build was never the part that failed.

Ownership assumptions cause the most damage

Many business owners assume that because they paid for a website, they automatically own everything connected to it: the domain, the hosting account, the code itself. UK law does not default that way. The government’s own guidance on intellectual property makes clear that copyright in work created by a freelancer or contractor generally belongs to the creator unless the contract explicitly assigns it to the client. A website built without that assignment written into the agreement can leave a business paying for something it never actually owns the rights to, discovered only when a dispute arises or the developer becomes unreachable.

The same applies to domains and hosting accounts. It is common, and often more convenient at the time, for a freelancer to register a client’s domain or set up hosting under their own account “to make things easier”. This works fine right up until the relationship ends on bad terms, or the freelancer simply stops responding, and the business has no way to access or move its own website. A simple domain lookup, checking who the registered owner actually is, takes a couple of minutes and settles the question with certainty rather than assumption.

Developer typing code on a laptop screen

Verbal promises do not survive a project actually ending

“I’ll send you everything at the end” is a promise made in good faith by most freelancers, and broken by circumstance more often than by bad intent. Projects wind down, priorities shift, and a task with no deadline attached to it, sending over login credentials and documentation, gets pushed further and further back until it is forgotten entirely. IPSE, the UK association representing self-employed professionals, has written about the practical importance of clear written terms in freelance engagements precisely because informal understandings tend to erode once a project is no longer actively being worked on by either side.

A handoff that exists only as a verbal promise is not a handoff, it is a hope.

This is not unique to disorganised freelancers. Even conscientious ones underestimate how much implicit knowledge sits in their head about a site’s setup, knowledge that never makes it into a document unless someone insists on it being written down before the invoice is paid. A developer who built a site six months ago can usually still answer a quick question about it from memory. A year on, with several other projects in between, the same question often gets a genuinely uncertain answer, not because the developer is being evasive, but because the details have simply faded the way any specific technical detail does once it stops being actively used day to day.

What a proper handoff actually includes

A handoff that genuinely leaves a business self-sufficient covers more than a zip file of code. It needs to include working access to every account the site depends on, and confirmation that each one has been tested, not just listed.

A reasonable handoff checklist includes:

Domain registrar login, with the business, not the developer, as the registered owner and billing contact.
Hosting account access, ideally created under the business’s own account from the start rather than transferred at the end.
A copy of the full site code and database, plus confirmation of which platform or framework it uses.
Written documentation of any third-party services the site depends on, such as email delivery, payment processing or analytics.
A final walkthrough confirming the business can actually log into everything listed, not just that credentials were emailed over.

Person signing a document with a pen

Getting this right from the start of the project

The cleanest fix for a bad handoff is preventing it, not repairing it after the fact. Anima’s writing on designer-to-developer handoff makes a related point about how handoff friction almost always traces back to decisions, or the absence of decisions, made at the start of a project rather than problems that emerge only at the end. The same logic applies here: agreeing ownership of the domain, hosting and code in writing before work begins costs nothing and prevents the entire category of problem.

Freelancer working at a laptop in a home office

Small businesses commissioning a freelance build, or inheriting one from a previous engagement, often only discover the gaps in a handoff when they need to make a change and cannot. This is the kind of situation pomegranate.marketing, a UK web design agency, regularly gets called in to untangle, taking over a site’s ongoing management once ownership and access have been sorted out properly.

Frequently Asked Questions

Who owns a website built by a freelance developer?

In UK law, copyright in commissioned work generally belongs to the freelancer by default, not the client, unless the contract explicitly assigns ownership. This makes clear written terms at the start of a project essential, not optional.

What should be included in a proper website handoff?

Working, tested access to the domain registrar, hosting account, full site code and database, plus documentation of any third-party services the site relies on. A list of credentials sent by email without a working walkthrough is not a complete handoff.

Why do freelance handoffs so often fail even with a good working relationship?

Handoff tasks tend to have no clear deadline once a project has technically finished, so they get deprioritised as the freelancer moves to other work. This happens even with conscientious freelancers, not only disorganised ones.

Should a business let a freelancer register its domain name for them?

It is common for convenience, but the domain should be registered under the business’s own account with the business as the billing contact, not the freelancer’s, to avoid access problems if the relationship ends.

What is the best time to agree handoff terms with a freelance developer?

Before the project starts. Agreeing ownership of the domain, hosting and code in the initial contract prevents almost every version of this problem, whereas trying to negotiate access after the work is finished is far harder.