Page Builders for Sites You Have to Hand Over

A web studio I know quotes handover as a line item. Two days, including a screen recording and a document, and the client signs it off alongside the site. They started doing that after a restaurant site came back four times in one month, each visit caused by somebody editing a menu page in a builder and dragging a column out of alignment because nothing on the screen told them not to.

None of those visits were the client's fault. The handover had given them an editor with no boundaries, and a maintenance path that lived only in the head of the person who built the site. That cost fell due later, on somebody else's invoice.

Builders are not the problem here. The problem is that "fastest to build in" and "cheapest to hand over" are two different measurements, and a builder can score well on the first and badly on the second for reasons that have nothing to do with how good the builder is.

What actually gets handed over

Handover is usually described as access: an administrator account, a hosting login, a domain registrar. That is the small part. The expensive part is the maintenance path, which has to survive the client's first panic.

Four things have to be true before you close the job. Somebody has to own WordPress core and plugin updates and know when they ran. Backups have to exist, be automatic, and be restorable by somebody who is not you. The licence renewals for every paid component have to be attached to an account the client controls, with a date in writing. And there has to be a named place to look when the site breaks, which is usually a document rather than a person.

A page builder changes two of those four. It adds a licence that renews, and it changes what counts as a safe edit. Both of those are handover decisions, made at build time, usually without anybody naming them.

There is a second cost that rarely makes the quote: the client now has an editing interface that is not WordPress. When they hire somebody new in year two, that person has to learn the builder before they can change a heading. Sometimes that is a five-minute job. Sometimes it is the reason the quote comes back higher than expected, which is the point at which clients start wondering whether the site was a good idea.

What a non-technical client can safely edit

The useful question is not "can the client edit the page". It is "what is the most damage a normal week of edits can do".

A builder tends to hand over one broad surface. Divi's visual builder is pleasant to use, and a client who can change a heading can also change the section background, the column widths, the spacing presets and the font stack, because those controls sit in the same panel as the text they came for. That is a feature for a client who wants to design, and a support contract for a client who does not.

Core is more granular. The block editor lets you lock a block so it can be edited but not moved or deleted, and a block theme's templates can be built so the client edits patterns rather than pages. A capability check can keep them out of plugin screens while leaving them able to publish. It is more work to set up, and it produces a site where the client can be trusted with a login.

The permissions model is where the two diverge most. A builder's interface is the whole layout, so granting "can edit posts" often means granting "can restyle the site". Roles in core are more surgical, which is worth the extra hour of setup on any site where the client has a login and a credit card.

When the client stops paying for the licence

This is the part of handover that nobody writes down, and it arrives about eighteen months after launch, usually during a quiet quarter. The client looks at a renewal invoice for something they do not recognise, decides it is not worth it, and stops paying.

The site does not go down. For Divi specifically, Elegant Themes states that after a cancelled subscription runs out, the buyer loses the members area, new theme releases, theme updates and technical support, and can keep using the themes already downloaded. The builder keeps editing. The pages keep rendering. What stops is the flow of fixes, and that is the part with a security consequence attached to it, because a page builder is code on every request and the theme alongside it is more code.

Two things follow from that. First, the renewal belongs to the client's account and not to your card, because a licence you keep paying for is a relationship the client never agreed to. Second, the handover document needs one paragraph explaining the difference between the site working and the site being maintained. Most clients have never had it explained, and the ones who understand it usually renew.

Elegant Themes sells Divi as an annual licence at Elegant Themes' pricing page, where the Divi Yearly plan is $89 billed yearly, which covers the builder, the theme and unlimited websites for a year, with a lifetime option on the same page that removes the annual decision entirely. For a handover, the lifetime plan is worth pricing against three years of renewals, because it converts a recurring conversation with the client into a line in the original contract.

Core is free but not free of cost. Somebody updates WordPress, watches for plugin breakage, and checks that the theme's patterns still match the design. On a small site that is an hour a month, and it is the hour that most often goes unplanned.

Handover documentation does more work than the builder choice

I have watched two sites with the same builder diverge completely, and the difference was the handover pack, not the tool. The pack that worked had four pages. The one that did not was a password sent by text message.

Write down the renewal date and the account that owns each licence, including the host and the domain. Write down what the client is and is not allowed to change, in their language, with screenshots of the screens in question. Write down how backups are restored, and test a restore before handover rather than after the incident. Write down the order of operations for a plugin update on this specific site, because a site with a builder has at least one plugin that must be updated after the builder rather than before it, and that sequence is knowledge you have and the client does not.

There is also a small set of settings worth changing at build time. Turn off the theme and plugin file editors in wp-config.php so no one can paste PHP into a screen. Keep the child theme small enough that a theme update cannot overwrite the client's changes. Give the client the lowest role that lets them do their job, and check that the role can actually reach the builder or the block editor, since a client who cannot edit anything finds the phone number faster than the documentation.

On a builder site, one admin setting deserves particular attention: whether the client can reach the plugin list at all. A builder that offers a module for a feature the client does not need is an invitation to install it, and every installed module is another update in the sequence you just documented.

The case for handing over something the client cannot break badly

There is a version of this advice that gets builders wrong. A client who has a well-built, tightly scoped builder site is often better off than a client on a bespoke theme that only its author understands, because the builder at least gives them another route to help. Divi is a known quantity, with documentation, a large user base and freelancers who will take the work. A hand-written theme with a custom options page has none of that. Handover cost is not the same thing as builder versus core.

The honest limit of my position is this. If the client wants to run campaigns themselves and change layouts weekly, a builder is not a handover risk, it is the requirement, and a core-blocks purist answer would cost them money and autonomy. If the client wants to change their opening hours twice a year, the builder's flexibility is paid for in maintenance they will never use.

I would decide it in the contract meeting rather than in the build. Ask what the client expects to change, ask who they will call when it breaks, and write both answers into the scope. If the second answer is "you, forever", then the builder is not the expensive part of that arrangement.

What to do before you hand over anything

1. Move every renewal onto a client-owned account and give them the date, in writing, before the final invoice. A licence on your card is a support contract nobody priced.
2. Write a one-page editing guide with screenshots of the screens the client will actually see, listing what they can change and what to call you about.
3. Lock what should not move: disable the file editors, keep the child theme minimal, and set every account to the lowest role that works.
4. Prove the backups by restoring one, and record the restore steps in the pack rather than in your memory.
5. Say out loud what a lapsed licence does and does not do. Clients renew when they understand it stops updates rather than the site.