Website Ownership Standard
A website should not become a hostage situation.
Managed development is useful. Technical captivity is not. We build custom sites with eventual transfer in mind because that pressure produces cleaner architecture while the relationship is healthy.
The exact legal ownership terms are governed by the project agreement. This standard describes the practical technical posture we want the work to meet.
The standard
Eight things the website should survive
Ownership is practical when another competent team can identify the source, deployment, content, domain, integrations, licenses, and transfer path without reconstructing the project from scratch.
The client can receive the source repository
For custom website work, the codebase is not meant to function as leverage against the company that paid for it. The repository, content files, configuration, and build logic can be delivered or transferred according to the engagement agreement.
The business domain should remain under business control
We can manage DNS and deployment details, but the company should know which registrar owns the domain, which account controls it, and how that ownership can be recovered without depending on us.
The deployment should be reproducible
A future developer should be able to identify the production project, build command, production branch, domains, environment requirements, redirects, headers, and external systems needed to run the site.
Content should have a portable source of truth
On our repository-driven sites, public content travels with the code. If a project uses an external CMS, the client should have access to that system and a practical export or transfer path.
External integrations should be identifiable
Forms, analytics, Search Console, ad tags, scheduling, CRM destinations, APIs, payment providers, and other external dependencies should be documented well enough that another team can understand what the site talks to.
Licenses and third-party dependencies should be explicit
If a font, plugin, image library, premium tool, or other service uses an agency-held license, the client should know what will need a replacement subscription after handoff.
Secrets are transferred securely, not buried in source
Credentials and private keys belong in managed environment configuration or the owning provider. They should not be committed to the repository merely to make transfer easier.
Leaving should be technically possible
Our goal is to make staying useful, not to make leaving painful. A healthy implementation gives the business a realistic path to another developer or host without rebuilding the website from screenshots.