The site is live. Can the client run it without you?

01Launch is not the same thing as handoff

A polished walkthrough can still leave the business dependent on the person who built the site. The dangerous gaps are usually mundane: the wrong account owns the project, renewal notices go to an old address, the domain sits somewhere nobody can name, or the only operating guide contains a password that should never have been copied into a document.

Treat handoff as a transfer of control and a small operating system. The client should know what they own, what they can change, what they pay for, what remains with the studio, and what happens when something breaks. This guide is an editorial worksheet, not a contract or legal opinion. Record any commercial and intellectual-property agreement separately with appropriate advice.

02Build one control sheet before you transfer anything

Swipe or scroll to compare

A row is not complete because a link exists. Record the responsible person and ask them to perform the acceptance proof. Mark anything that cannot be verified as unknown; do not turn an assumption into a green check.

03Choose the operating model before the platform transfer

Swipe or scroll to compare

Webflow documents that the Workspace containing a site owns it: letting a client manage billing does not itself give transfer or duplication rights. Its client seats can separately grant marketer, content-editor or reviewer roles, with publish and payment permissions chosen during invitation. [1][2] That separation is the reason the worksheet keeps ownership, billing and edit access in different rows.

Framer documents that a Project Transfer keeps the site and connected custom domain online, while the recipient becomes owner after acceptance. The active site subscription is then canceled, unused value is credited to the original owner, and the new owner chooses and pays for a required plan. Framer also says each editor should use an individual account rather than sharing one login. [3][4] Confirm the current behavior in the platform before a live transfer; these controls can change.

Squarespace documents another coupling: changing the site owner also transfers attached subscriptions such as Squarespace domains and Acuity scheduling, while its Payments account can require a separate manager transfer. [5] A universal instruction such as “transfer the site” is therefore too vague. Name the platform, affected services and expected result.

04Keep passwords out of the handoff document

The operating guide should point to an approved secrets system and name the item, owner and recovery path. It should not contain passwords, API keys or recovery codes. OWASP recommends centralized lifecycle management, fine-grained access and least privilege; its documentation checklist includes who has access, how a secret is rotated, dependencies, incident contact and exposure impact. [6] Use the current instructions for the chosen password or secrets manager when implementing the transfer.

• Give each person an individual account where the platform supports it. Do not turn one founder or agency login into a shared credential.
• Grant the smallest role needed for the agreed job; ownership, billing, editing and publishing are separate decisions.
• Rotate or revoke credentials that no longer need to survive the handoff. Record the trigger and responsible owner rather than the secret value.
• Test recovery with a permitted non-destructive path. Do not lock out the working owner merely to prove the checklist.

05Use AI for the draft, not the ownership decision

A useful drafting instruction is: “Using only the approved handoff inventory below, prepare a client operating guide. Keep every service owner, payer, role, renewal date, recovery path and maintenance responsibility explicit. Mark missing values UNKNOWN. Do not infer ownership, include secret values, promise an unperformed transfer, or change any account. End with an acceptance checklist and questions requiring a named person.”

Review the draft against the platform screens and source records. AI can shorten notes, normalize naming and surface blank fields. It cannot know that a transfer was accepted, a bill will be paid, an account is recoverable, or a licence permits reuse unless inspected evidence says so.

06Run a thirty-minute acceptance test

• The client signs in with their own account and identifies the current project or workspace owner.
• They locate the plan, next renewal and billing contact, then explain what changes after transfer.
• They locate the domain registrar and DNS host without sending credentials through chat or email.
• They perform one agreed content edit in a safe page or draft and identify who is allowed to publish.
• They find the analytics or form destination and inspect one permitted test event—or record the untested dependency.
• They locate one approved asset and the source repository or file store.
• They use the maintenance matrix to route a normal change, an urgent outage and a request outside scope.
• Both sides record accepted items, unresolved questions, retained access and the date the next access review occurs.

Stop the transfer if a critical owner, payer, recovery path or data destination is still unknown. A screen recording is helpful training, but it does not replace account ownership or a tested recovery route.

07Compare maintenance options with the full cost

Swipe or scroll to compare

For a bounded experiment, use this sheet on three future handoffs only when the work naturally occurs. Record preparation minutes, client acceptance minutes, unresolved critical fields, clarification messages during the next fourteen days and any access correction. Compare with your previous process only if those records are genuinely comparable. No client trial, time saving or failure reduction is claimed here.

Sources are linked above so the argument can be checked independently. Editorial revisions retain the same public address.