What a client should own after a custom website project

A client should not have to stay with a developer because leaving would break the website.

That does not mean every service has to be portable with one click.

It means the client should understand what the website depends on and have a practical path to take control of the assets they paid for.

We design our handoff model around that principle.

The source code is the starting point

For a custom-coded site, the repository is the durable representation of the application.

The client should be able to receive or control access to that repository.

That includes the routes, components, styles, content files, configuration, and build scripts required to reproduce the project.

A ZIP of generated HTML is not the same thing as the source.

Our guide on why Git history is part of the client handoff explains why the history matters too.

Domain ownership should be clear

The business domain is one of the most important digital assets the company owns.

The client should know which registrar controls it, which account owns it, where DNS is managed, and who can make changes.

A developer can manage DNS as part of the service without becoming the only person who can recover the domain.

The ownership model should survive a relationship change.

Deployment should be reproducible

A future developer should be able to answer:

Which hosting project runs production?

Which branch deploys?

What build command is used?

Which environment variables are required?

Which domains point to the deployment?

Which redirects or headers are configured?

That information can live partly in the repository and partly in the hosting platform.

The important thing is that it is not trapped in one developer's memory.

Content should be transferable

On our MDX-based sites, public content lives in the repository.

That makes articles, service pages, locations, and documentation portable with the code.

A CMS-based project has a different handoff requirement. The client needs the CMS account, database or export path, media, and any configuration required to reproduce the content.

The format can differ. The ownership principle does not.

External integrations need an inventory

Most production websites depend on systems outside the repository.

Those can include:

• form providers
• analytics
• advertising tags
• scheduling tools
• CRM destinations
• email systems
• APIs
• CAPTCHA or abuse controls
• payment providers
• image or media services

A handoff should identify the integrations and explain which accounts belong to the client.

Credentials themselves should be transferred through secure channels, not committed to source.

Analytics data should not disappear with the agency

Traffic and conversion history can be valuable.

The client should know which analytics properties, tag managers, ad accounts, and search tools are collecting data and who owns those accounts.

A website migration should not casually destroy continuity because the old agency created every property under an account the client cannot access.

Licenses need special attention

Some tools are licensed to an agency rather than the end client.

That is not automatically a problem.

The handoff should make the dependency explicit.

If a premium library, plugin, font, image license, or service needs a new subscription after transfer, the client should know before the old license is removed.

Documentation matters more as the site becomes an application

A simple marketing site may need only a short handoff.

An application with authentication, databases, APIs, background jobs, mobile wrappers, or third-party services needs more.

The level of documentation should grow with the number of systems a future team has to understand.

The client does not need every internal tool

Ownership does not mean the client has to receive our internal project-management history, local development environment, or unrelated company tooling.

The handoff should focus on what is required to operate, reproduce, maintain, and move the website.

That boundary keeps the package useful instead of dumping irrelevant internal material on the client.

Leaving should be technically possible

This is the part we care about most.

We want clients to stay because the ongoing work is valuable, not because moving the site is intentionally painful.

That changes how we think about architecture from the beginning.

Repository content, predictable deployment, limited hidden state, explicit integrations, and controlled dependencies all make future transfer easier.

Good handoff architecture improves development too

A codebase built with eventual transfer in mind tends to be cleaner.

Developers are less likely to rely on undocumented manual steps.

Configuration has to be understandable.

External systems need names.

Content needs a clear source of truth.

Builds need to be reproducible.

The possibility of handoff creates useful discipline long before the handoff ever happens.

That is why ownership is not a legal footnote at the end of a project. It is one of the constraints that shapes how we build the site.