Transfer a Carrd site to a client: a handoff readiness checklist

Decide whether the client needs ownership or editing access

A client who only needs to update text has a different requirement from a client who will own and maintain the site after the project ends. Write down that distinction before choosing an action. Your handoff should identify who controls the site, who pays for it, and who answers when something stops working.

Carrd documents sharing and transferring as separate operations. Its sharing guide allows Admin and Editor access for users on the free Basic plan while the owner provides the relevant paid features. A transfer changes ownership and requires the receiving account to support the site.

Carrd's transfer, sharing, and contact-form documentation was reviewed September 20, 2026. We have not transferred a live client site or tested post-transfer integrations. The original local exercise below tests how an evidence record handles missing and stale observations; it does not test Carrd.

Run the receiving-account preflight

Carrd documents Pro Lite or higher for initiating a transfer. The receiving user needs an active account, access to the features used by the site, and an available site slot. The recipient must accept the request to complete it. If you mean to give away a copy, Carrd instructs you to clone before transferring.

Inventory actual elements rather than looking only at the published page. A simple-looking site can still contain a form or other feature with a plan requirement. Compare each used feature with current documentation and have the recipient check their own account. Do not ask for their password.

Give forms an explicit owner

Carrd contact forms can use the account email by default or specified recipients. Its current contact-form documentation requires Pro Standard or higher. Do not infer the intended destination from the visible contact text: inspect the form configuration and record who should receive the message.

Use a harmless test message agreed with the recipient. Record submission time, destination, whether delivery arrived, and whether replying reaches the intended sender. Avoid putting real customer messages in your handoff worksheet. A success message on the website alone does not prove inbox delivery.

If a site uses an external form, booking service, or payment link, list it separately. The transfer documentation cited here does not establish that ownership, credentials, billing, or delivery settings for those services transfer with the page.

Separate the site from domain and service responsibilities

Create one row for each dependency: Carrd ownership, domain management, DNS changes, contact inbox, booking destination, and any externally managed assets. Record the responsible person and a verification step. This is a responsibility inventory, not an instruction to transfer the domain or change DNS unnecessarily.

For example, if the client already owns the domain, the relevant question may be who maintains its website records after handoff. If an agency owns a booking account linked from the page, the client needs an agreed destination and access plan. Do not mark an account as handed over merely because a link still opens.

Identify who handles the domain, DNS, and email — Automation Tools Compared — Use the service breakdown when the client needs help assigning an owner to each dependency.

Sign off one visitor journey after acceptance

• Have the new owner open the site from their own account and confirm the agreed editing access.
• Open the public page on a phone and desktop. Check the headline, navigation, primary action, and any download or external destination used in the project scope.
• Complete the agreed form or booking test and record the outcome. Where an external transaction would cost money, use the service’s authorized test path or agree the test separately.
• Record any known limitation, its owner, and the next action. A pending item stays pending; do not convert a deadline into a pass.
• Agree whether the original builder keeps any access and for how long. Review access deliberately after acceptance instead of assuming it disappears automatically.

Original exercise: acceptance is not inbox delivery

We ran the downloadable carrd-handoff-rehearsal.mjs locally on September 20, 2026. It evaluates four invented records against seven documentary checks: receiving-account readiness, transfer acceptance, dependency owners, new-owner access, phone and desktop visitor checks, inbox receipt, and reply receipt. It makes no network requests and sends no messages.

The first case contains a sent request but no acceptance. Its later-looking access and delivery records cannot complete a post-acceptance check. The second records acceptance and website success but has no inbox evidence. The third contains a receipt and reply from before acceptance. Only the fourth has all seven records in the required order.

These results measure the local record-checking logic, not actual account ownership or email delivery. A reference is a label supplied in the fixture, not a verified document. All seven records can be fabricated, so even 'record complete' requires a person to inspect the underlying evidence. The seven checks are a bounded teaching example, not a complete project acceptance standard.

Reproduce and challenge the evidence record

Download the source below and run node carrd-handoff-rehearsal.mjs with Node.js 22 or later. No package installation is required. The JSON output lists each case, its seven checks, and the next action for every pending check. The program writes only its terminal output.

To inspect a failure, change the complete fixture's inbox recipient to a different example address, remove its receipt reference, or make the receipt older than the acceptance timestamp. Rerun and check that the inbox-delivery item stays pending. A reply tied to a different message must also remain pending. Restore the original source before comparing the four published results.

Use the separate client handoff worksheet in the resource library for real project notes. Keep real inbox contents, personal addresses, credentials, and recovery codes out of the sample source. Agree any live visitor or email test with its owner before performing it.

Close the project with a usable record

The client handoff worksheet in the resource library includes an ownership decision, feature inventory, dependency owners, and acceptance log. Keep it with the project’s existing records. Store passwords and recovery codes through your established credential process, not in this worksheet.

A good handoff lets the client answer three questions without contacting the builder: what do I own, what needs renewing, and what do I do when the main visitor action fails? That is more useful than a screenshot saying the transfer request was sent.

Sources & verification

Product details and prices can change. Check the linked provider before buying.

1. Carrd: transferring a site Accessed 20 Sep 2026
2. Carrd: sharing access Accessed 20 Sep 2026
3. Carrd: setting up a contact form Accessed 20 Sep 2026