Client Handoff: Who Owns the Site, and Who Pays for It

Client handoff is the part of a builder project that nobody designs and everybody eventually regrets. The work ships, the invoice is paid, and then the site sits on your account, billed to your card, with a client who assumes they own something they cannot access. Two years later you are paying for four former clients and having an awkward conversation about each.

All of it is preventable, and the prevention happens before the proposal rather than after the launch. There are four decisions, they take ten minutes, and getting them wrong is the most common way a profitable project becomes an unprofitable relationship.

Decision one: whose account is this?

There are two defensible models. In the first, you build in your own account and transfer the site at the end. In the second, the client creates the account from day one and adds you to it. Both work; what does not work is drifting into the first while assuming the second.

Build-then-transfer suits studios: you keep your tooling, your libraries and your conventions, and the client receives a finished thing. Client-owns-from-day-one suits clients who have an internal team, and it removes the transfer step entirely — at the cost of you working inside someone else's account settings.

Whichever you pick, write it into the proposal in one sentence. The sentence costs nothing and it converts an assumption into an agreement.

Decision two: who pays the subscription, and from when?

This is the one that quietly bleeds money. Platform subscriptions do not stop when a project does. If the plan is on your card at launch and nobody changes it, it is still on your card at the next renewal, and the client has no idea.

The clean version is to state a date: the client assumes billing at handover, or thirty days after launch, and the proposal says so. If you are absorbing hosting as part of a retainer, say that too, and say what happens to it when the retainer ends — which is the clause studios most often omit and most often need.

Budget the number honestly while you are there. On Webflow a client inheriting a CMS site is inheriting a Premium site plan at $25 a month billed yearly, plus whatever workspace and seats they need. On Framer they are inheriting a Basic or Pro plan at $10 or $30 a month billed yearly, plus editor seats. A client who learns this at handover feels ambushed; a client who saw it in the proposal budgeted for it.

Decision three: what access do they get?

The instinct to hand over full access is usually wrong, and the cheap restricted roles exist precisely for this. A client who needs to update case studies and swap photographs does not need the ability to change the type scale, and giving it to them is how a design you are proud of becomes a design you do not mention.

Framer's content-editor seat at $10 a month covers CMS work, localisation and on-page editing without design access. Webflow's limited seat at $15 a month billed yearly covers content editing and page building from existing components. Both are the correct default for a client relationship.

Full design access is for clients with a designer on staff. Everyone else is better served by the constrained role, and framing it as protection for their investment rather than as a restriction is both more accurate and easier to sell.

Decision four: what happens if they leave the platform?

Answer this in the proposal, accurately, in one sentence per platform. On Webflow: the design and static pages can be exported as HTML and CSS from a paid workspace, and the CMS content cannot. On Framer: nothing exports, and moving means rebuilding. Neither sentence loses work when it is said early. Both cause arguments when they are discovered late.

If a client's procurement process requires portability in writing, that requirement makes the tool choice for you, and it is far better to discover it during a proposal than during a handover. The full comparison of what leaves each platform is on the best website builders for designers.

The mechanics, briefly

Webflow supports transferring a site between workspaces as a normal operation, listed under site management on its pricing page. The site moves to the client's workspace with its plan, and their payment method takes over. It is the most mature version of this in the category and it is the main reason Webflow suits studios that do a lot of client work.

Framer's path is generally to bring the client into the project with an editor seat, or to move the project to their workspace. Either way the practical step is the same as everywhere: the person holding the payment method changes, and somebody has to actually do it on a specific day.

Put that day in the project plan as a task with a name against it. "Transfer billing" is a fifteen-minute job that costs hundreds of pounds a year when it stays on a mental list.

The retainer question, answered early

Handover and retainer are usually discussed as alternatives, and they are not. A site can transfer to the client's billing while you keep a small maintenance arrangement, and that combination is often the honest one: they own the asset, you remain the person who knows how it was built.

The reason to separate them explicitly is that a retainer ending should not silently leave a subscription behind. Tie the billing transfer to launch, not to the end of the relationship, and the two can conclude independently without either one stranding the other.

A handover note worth writing

One page, given at launch, containing: which platform the site is on, which plan and what it costs, who the account belongs to, what the client's role can and cannot change, how to add a new page or post, and what to do before touching anything structural. Nobody expects it, everybody keeps it.

It also protects you. A client who breaks a layout six months after launch having been told not to edit structure is a support conversation. A client who was told nothing is a complaint about the quality of the build, and you will have no evidence to the contrary.