Hand off to the client

You built the site. The client should be able to edit it, and should not inherit invoicing, quotes and customer email sends they never asked for and will phone you about. Three decisions, in this order.

1. Invite them as an editor, not an owner

Settings → Members → invite by email. The invitable roles are editor and viewer; owner is not a value the invite accepts, so the account stays yours. The client signs in with that same email address to pick the invite up.

• Editor - can change the whole website and publish it.
• Viewer - can look and change nothing.

Choose the reach at the same time: one website, or a whole company (every site in it, including ones you add later). Only the owner can invite, re-role or remove.

Source: convex/invites.ts, convex/members.ts.

2. Decide what they may use

Once somebody else has access, Settings → Medlemmar → "Vad din kund kan göra" ("What your client can do") appears for the workspace owner. It is invisible in a solo account, which catches agencies out: set the account up, invite the client, then the setting exists.

• Endast hemsidan ("Website only") applies the preset - everything controllable off, leaving the website editor and publishing.
• Below it, each area opens into per-feature switches with a whole-area switch of its own.

The rows are phrased as what the client gets; the stored value is the inverse (a list of withheld ids), because an agency thinks in what it grants.

What is switchable today - and only this:

Bookings, services, domains and the AI surfaces are not switchable. The rule is deliberate and worth knowing before you promise a client anything: a feature enters the registry only once the Convex functions behind it refuse a direct call with it switched off. Hiding a door is not a permission - the client's browser can call the function whether or not the sidebar shows the row. The registry grows to match enforcement, never the other way round (lib/features/client-controls.ts, held honest by convex/lib/clientFeatures.guard.test.ts).

A switched-off area disappears - no locked button, no "ask your agency" screen. Navigation, command search, settings tabs and deep routes all drop it, and a stale bookmark returns to the website overview. Enforcement is on the server, so a direct call is refused with a plain FORBIDDEN rather than a distinct "feature disabled" code, and it reaches MCP as well: an agent connected by the client cannot read or send what the switch withholds.

Data is untouched. Switch a feature back on and everything returns as it was; nothing needs re-creating. Invoices and quotes that already exist stay payable and acceptable by the client's own customers, because those public recipient endpoints authenticate by document token and are deliberately exempt - a third party should never notice an agency setting changed.

One setting per workspace, not per person. Every non-owner member of the account gets the same limits.

3. Know what transferring ownership does

Transferring the workspace to the client voids every limit you set. The limits never apply to workspaces.ownerUserId - the owner is exempt by design, because the switches are the owner's own tool. Hand the account over and the client is the owner, so nothing is withheld from them any more.

This is the one thing an agency can get wrong, and it is silent: the settings row still shows your switches, and they no longer bind the person you set them for. Two further consequences of the same move (transferOwnership, convex/members.ts):

• You are demoted to editor, not evicted - and you are then subject to the limits, since you are no longer the owner.
• It is blocked while a subscription is still billing (active or past_due), so nobody is left paying for someone else's site.

So: if the client should keep working under limits you chose, do not transfer ownership. Invite them, keep the account, and set the switches. Transfer only when you intend to end the relationship and hand over the whole business.

The handover control sits on the same Medlemmar tab, below the invite list.

What this is not

Not a public role system, and not per-site: the unit is the workspace. It does not change what you can do, and it does not do white-label branding.

The client's own version of this page

The customer-facing help page for the same feature is Let someone help you - English · Swedish. Send the client that one; it is written for them and the Swedish overlay is what most owners actually read.

Internal reference: docs/features/account-and-billing/client-feature-control.md.

---