Ownership, handoff, and long-term maintenance

A website is not fully owned just because a contract says the client owns it. Ownership has a technical reality. Can the client obtain the source? Can another developer run it? Can the domain be moved? Can the content be exported without scraping the public site?

Can the forms be repointed? Can somebody identify the analytics, environment variables, and external providers? Can the application be deployed without the original developer manually reconstructing a hidden process? Those questions matter more than a sentence that says "work product belongs to client."

The repository is the core asset

For our custom sites, the repository contains the actual implementation. That includes much more than the visible markup:

• routes
• components
• styles
• content
• metadata logic
• structured data
• image handling
• form boundaries
• build scripts
• validation
• deployment configuration

A static export may reproduce the current appearance. A repository preserves the system that can create the next version.

Content should leave with the code

This is one reason we like repository-based MDX for managed sites. Articles, documentation, location content, service copy, and other long-form material can live with the project. Handoff does not require a special database export just to preserve the words. That is covered in Why our website content usually lives in the repository.

Git history is part of the asset

The current files tell a future developer what the site is. The commit history helps explain how it became that way. That can reveal why a responsive fallback exists, when a content rewrite happened, which release introduced a route family, or what changed around a performance regression.

Read Why Git history is part of the client handoff.

Hosting is a service, not leverage

We are comfortable hosting and managing sites. We do not want the hosting arrangement to become the reason a client is unable to leave. A clean repository and understandable deployment model make transition possible. There can still be practical migration work. Domains, environment variables, form providers, analytics properties, email systems, and third-party accounts all need correct ownership and transfer steps.

The goal is not "one-click departure." The goal is "departure is technically possible without rebuilding the website from zero."

External systems should be identifiable

A future maintainer needs to know what the website talks to. That can include:

• form providers
• analytics
• advertising tags
• CRM endpoints
• maps
• image services
• email systems
• APIs
• authentication providers
• payment providers in application projects

We prefer explicit integrations over mysterious scripts pasted into an admin panel years ago. The more visible the boundary, the easier it is to replace.

Environment variables are part of handoff planning

Secrets should not be committed to the repository. That means a handoff needs a controlled process for recreating the environment. The code should make it reasonably obvious which variables are required. The credentials themselves should be transferred through an appropriate secure channel or recreated under the client's ownership.

This separation is healthy. Source code and secret material have different security requirements.

A transferable site changes our own engineering choices

Knowing that another developer may inherit the code discourages shortcuts. One-off magic values become more expensive. Undocumented manual steps become less acceptable. Content models, shared metadata helpers, route families, validation scripts, and predictable file structure become more valuable. Handoff pressure improves architecture.

Maintenance does not end at launch

Frameworks change. Browsers change. Search behavior changes. Third-party APIs change. Business services change. New pages are added. Old pages become inaccurate. A website that stays useful needs maintenance even if the visual design does not change. That maintenance can be proactive or reactive.

We prefer proactive.

Technical maintenance and marketing maintenance overlap

A new service may require a new route, metadata, internal links, sitemap entry, article support, and conversion path. A site-speed regression may come from a marketing script. A ranking problem may come from a content rewrite, internal-link change, canonical issue, or changing search demand.

The idea that "development" and "SEO" are completely separate becomes less useful once a site is being actively managed. This is part of why our development and search work stay close together.

Portability is not the same as no dependencies

A real site will depend on frameworks, packages, deployment infrastructure, and external providers. The standard is not zero dependencies. The standard is understandable dependencies. A competent developer should be able to identify what each major dependency does and what would need to change if it were replaced.

The client should have options

This is the principle underneath the rest. We want a client to stay because continued work produces value. We do not want them to stay because the technical system is deliberately impossible to untangle. A well-structured handoff is one of the tests of whether the website was built as a real asset.

If another developer can inspect the repository, understand the architecture, recreate the environment, and continue the work, the ownership promise has substance.