Ownership guide

The business should control the accounts that determine whether it stays online.

A website is easier to maintain, transfer, and recover when ownership follows business responsibility instead of living permanently inside a developer's personal account.

The short answer

The client business should usually own the production domain, hosting, business email, analytics, payment, booking, messaging, and customer-data accounts. A developer can receive the least-privilege access needed to configure and support them.

Why the domain matters most

The domain is the public address for the website and often business email. If renewal, billing, or recovery belongs only to a departing vendor, moving the website does not fully restore control. Keep registrant access, recovery methods, and renewal visibility with the business.

Use an ownership table

SystemPreferred ownerDeveloper access
Domain registrarClient businessDNS role when available
Production hostingClient businessTechnical/admin role
Analytics/search toolsClient businessAppropriate user role
Payments/POS/bookingClient businessOnly what scope requires
Customer dataClient businessLeast privilege, time-bounded

What the handoff should include

  • A list of production systems and their owners
  • Where billing and renewals are managed
  • How access can be removed without breaking the site
  • Backups, exports, and recovery responsibilities
  • What maintenance is included and what is not

If a developer disappears

The goal is not zero dependency; it is recoverable dependency. A new qualified person should be able to identify the systems, obtain authorized access from the business, and move forward without impersonating the former developer.

Exploratory inquiry

Have a real problem to untangle?

An exploratory email starts a conversation only. It does not authorize work, create a contract, or open a payment path.

See the inquiry boundaries