The handoff problem: why your client can't edit the site you built them

The build is done. The client has approved it. You hand it over, and two days later there's a message asking you to change a heading, because they couldn't work out how to change it themselves.

If you've run an agency for more than a month you know this message, and you probably know the tone of voice it arrives in. I don't think it's a client problem. I think it's a tooling problem, and the two versions of it I see most often are these.

#The two ways handoff goes wrong

The page builder hands them the keys to everything. Visual builders let the client edit anything, and "anything" includes the things that should have been locked. The layout, the section order, the button that was supposed to be a link and is now a button. The site drifts, and six months later you get a different message asking you to put it back the way it was, except there's no "the way it was" left to put it back to.

The CMS is a separate product with its own bill. Headless content platforms fix the drift by separating content from presentation, which is the right idea. But now the editor is a second product the client has to learn. It lives on the vendor's domain rather than the client's. The site's structure is expressed in that vendor's model, and the seats are metered. One editor for the client, one for their marketing hire, one for the intern who posts the blog, and each of those is a line item on your invoice until you find a way to pass it on.

What an agency actually wants is narrower than either of those tools gives you: an editor the client understands after one walkthrough, with no way for them to break the structure, no per-editor bill, and their own domain on the front of it. Plus a handoff you don't have to rebuild from scratch for the next client, which is the part I care about most.

#What handoff looks like when the editor is part of the site

On Tessryx there are two editors, and both come out of the same definition that shapes the site's data. The first is generated automatically inside the Tessryx app, for your team. The second is one the agent builds into the site itself, for the client's people. Neither one is a separate product bolted on next to the site. They're derived from the data, which is also why they can only ever edit what the data allows.

#The form comes from the schema

Every piece of content on a Tessryx site follows a schema the agent wrote when it built the site. Because the schema describes the data's shape, the platform knows exactly what form to draw, field by field. A short text field gets a text box and a long one gets a Markdown or rich-text editor. Images get an uploader. A fixed set of choices turns into a dropdown, and a list of team members turns into a stack of little name-role-photo sub-forms that can be added to and dragged around. Nobody has to configure any of that. The agent designs the data and the editor turns up in the Tessryx app, typed and labelled, with whatever help text the agent wrote. Anyone with a workspace seat can use it.

#They cannot break the structure

The schema does double duty. It draws the form, and it also validates every edit against the same rules before the edit is saved. A client can change the copy, swap the hero image, add a testimonial, reorder the FAQ. They can't turn a list into a paragraph or delete a required field or move a section, because the form doesn't offer any of that, and the validation would refuse it anyway.

The rule I built the platform around is the one every agency lands on eventually: clients change content, and the logic that renders it belongs to whoever built it. Copy, prices, images and listings live in content the client edits. The logic that renders them lives in a workflow the client never sees.

#Edits are drafts until someone publishes them

A saved edit is a draft. The live site doesn't change until the draft is published, so a client can rewrite the pricing page all afternoon with no danger of half-finished copy going out. Their editor shows a small marker when the draft differs from what's live, and if a publish turns out to be wrong, re-publishing the previous version is the undo.

#Roles do the gating in the workspace

Workspace roles are cumulative and there are only five of them. A client contact with a seat can be an Editor: they edit and publish content and upload media, and they can't touch schemas, pages, workflows, integrations or domains. Your people are Maintainers and build everything. An Admin sets secrets and domains. That's the whole permission model. You set it once per person, and never per page. Each plan includes a fixed number of seats, so this is the right shape for a client's one or two named people. It's the wrong shape for their whole team, which is what the next bit is for.

#The admin can live on their domain, with no seats at all

For everyone else there's the second editor. The agent can build an admin page into the site itself: a page at the client's own address, in their own design, made from the same pieces as the rest of the site, gated behind a sign-in where the app decides who may edit. The people who use it are app users, not workspace members. They're unlimited on every plan and never take a seat. A client with twelve people updating the site through its own admin page pays the same as a client with two. Same for a members' site with two thousand accounts versus twenty.

The live example is the gated editor behind blog.nickpage.tech. It's a public blog with an admin at the same domain that only the blog's people can open, built from the same primitives by the same agent.

#Setting it up for a client

There's no separate "handoff" step. It's just how the site gets built.

1. One workspace per client. Workspaces are the unit of ownership and billing, and you can belong to as many as you like. Either you own the client's workspace and they're Editors in it, or they own it and you're a Maintainer. Both work fine. The second is cleaner if the client might leave one day, and leaving is a real option either way: an app exports as a zip of its definitions and imports into any other workspace, so a client who moves on takes the whole site with them rather than a screenshot of it.
2. Connect your agent to that workspace and build there. A connected agent is authorized against one workspace, so you connect it again for the next client.
3. Design the content for the client, not for you. Ask the agent to put everything the client will ever change into content records, with labels and help text a non-technical person will understand. More than anything else, this is what decides how the handoff goes.
4. Decide which editor they get. One or two named people can take workspace seats and use the generated forms. For a whole team, or for a client you'd rather keep out of the workspace entirely, ask the agent to build the admin into the site, so their people sign in on their own domain and never need a seat.
5. Walk them through one record. The rest of the editor works the same way, and they'll work that out faster than you'd expect.
6. Put the domain on it. Their address, their site, and an admin page at that address for the people who run it.

The message you get two days later then reads "can you add a field for the opening hours?" I'll take that one.