How to Choose a Page Builder or Theme for Client Websites: Handoff, Licenses, Lock-in, Exit Cost, Performance and Accessibility

The builder or theme you choose for a client site will probably outlive your involvement with it. Someone else may maintain it in three years. The client may want to leave you, change hosts or redesign. The license may lapse. The tool may be abandoned, sold or rewritten. The choice that felt fastest during the build can become the most expensive part of the site’s life.

This guide is for designers and agencies choosing a page builder, block theme or classic theme for client work. It deliberately does not recommend a product. Every option, including the WordPress block editor, has trade-offs, and the right answer depends on your clients, your team and your skills. Instead it gives you criteria and practical tests: handoff, licenses, lock-in, exit cost, performance, accessibility and longevity, plus a scoring sheet you can use to compare your shortlist on evidence rather than habit or marketing.

What you are really choosing

A builder is not just an editing interface. It decides:

• Where the content lives and in what format: ordinary HTML and blocks in the post content, shortcodes, or a private data structure stored elsewhere in the database.
• What the client can safely edit, and how easily they can break the layout.
• What the front end sends to visitors: the HTML, CSS and JavaScript that shape speed and accessibility.
• Who pays what, forever: licenses, renewals and the cost of leaving.

Judge each option on the client’s whole life with the site, not only on how fast you can build the first version.

The criteria at a glance

Criterion	The question to answer	How to test it
Handoff	Can the client edit content without breaking design?	Give a non-technical person a task on a test site and watch
Licenses	Who holds the license, and what happens if it lapses or you leave?	Read the license terms; let a test license lapse
Lock-in	What is left if the builder is switched off?	The exit test, below
Exit cost	How many hours would it take to move away?	Estimate from the exit test
Performance	How heavy is the front end for the same content?	Build the same test page in each and measure
Accessibility	Is the output semantic and keyboard usable?	Keyboard test and an automated checker
Longevity	Will it be maintained and secure in five years?	Release history, security record, compatibility notes
Team fit	Can someone else maintain it after you?	How easy is it to hire or hand over to people who know it?

1. Handoff: can the client live with it?

A site that only you can safely edit becomes a support burden or an unhappy client. Check:

• Editing for non-designers. Can the client change text, swap an image and add a page from a template without touching spacing, fonts or colors?
• Guard rails. Can you lock layouts, limit which elements or blocks editors see, or give editors a role that only edits content?
• Global styles and reusable parts. Are colors, type and buttons set in one place, so a later redesign is a settings change rather than editing every page?
• Training. Can you teach it in one session and document it on a page or two? The handoff document and training checklist is a good test: if you cannot fill in the training section simply, the client will struggle.

Run a real test: give a colleague or friend with no builder experience three tasks (edit a heading, replace an image, add a new page based on an existing one) and watch where they get stuck.

2. Licenses: who pays, and what happens when they stop

Many premium builders and themes are sold on annual or lifetime licenses, often with agency plans that cover many sites. The code of most WordPress plugins and themes is distributed under the GPL, but updates, support and some features usually depend on an active license key. Questions to answer in writing:

• Whose name is on the license? If it is your agency license, what happens when the client leaves? Some vendors allow transfers, some do not.
• What happens when a license lapses? For some products the site keeps working without updates; for others, premium features or the editor itself may stop working or show notices. Test it, or ask the vendor and keep the reply.
• What does the client pay over five years? Include the builder, any add-on packs and premium plugins the design depends on.
• Is the license allowed on client sites under your plan, and on staging copies?
• Monthly, annual or lifetime? Turn each into a monthly cost per site, and count seats: a plan limited to a set number of sites forces a second license when you pass it. A lifetime deal is only good value if the vendor keeps updating the product, so treat it as a risk as well as a saving.

Write the answer into the contract and the handoff document. The website project contract outline has a licenses section, and the renewals register tracks renewal dates. Running unlicensed or “nulled” copies is never the answer; the inherited site takeover playbook explains why.

3. Lock-in: run the exit test

The most useful test you can do takes about an hour. On a staging copy (never the live site), build two or three typical pages with the builder, then:

1. Deactivate the builder (and its theme, if it has one) and switch to a default WordPress theme.
2. View the pages. What is left? Readable text and images in a plain layout is a gentle exit. Raw shortcodes in square brackets, or an empty page, means a hard one.
3. Check where the content lives. Open a page in the block editor or look at the post content in the database. Is the text there, or is it stored only in the builder’s own data?
4. Check headers, footers and templates. Are they built in the builder too? They will need rebuilding.
5. Reactivate and check everything returns as it was.

This tells you more than any comparison article, and the result can change between major versions of the same product, so repeat it when a builder releases a major rewrite. If you have inherited a site where the exit is hard, the guide to WPBakery and Avada problems on inherited sites covers planning a move away from an abandoned builder, and page builder broke after an update covers update breakage.

4. Exit cost: put a number on it

Turn the exit test into an estimate. Count the pages and templates on a typical client site, estimate the hours to rebuild each in something else, and multiply by your rate. Add time for redirects if URLs change, retesting forms and retraining the client. That number is the real price of lock-in, and it belongs in your decision and in an honest conversation with the client.

A gentle exit is not only about leaving one day. It is also what lets another designer take over without a full rebuild, which is a genuine benefit you can explain to clients.

5. Performance: measure the same page in each

Do not compare demo sites; they are tuned to look fast. Build the same simple test page in each option on the same hosting: a header, a hero with one image, three cards, a form, a footer. Then measure:

• HTML size. From a terminal on your own computer, curl -s https://staging.example.com/test-page/ | wc -c prints the number of bytes in the HTML. -s hides progress output; wc -c counts bytes.
• DOM size. In the browser, open developer tools, go to the Console and run document.querySelectorAll('*').length to count elements. Deeply nested wrappers inflate this. The DevTools cheat sheet explains the panels.
• CSS and JavaScript. In the Network panel, reload with the cache disabled and note the total transferred size and number of requests for CSS and JS. Check whether the builder loads assets only on pages that use them.
• Core Web Vitals. Run a lab test, then watch real-user data once sites are live. Our guides to LCP, CLS and INP explain each metric, and the speed check gives a quick reading.

Keep the results in a simple table. A tool that is heavier but saves you significant build time can still be the right choice for some clients; the point is to know the trade-off. Fonts, images and animations matter as much as the builder: see slow websites: images, fonts and animations.

6. Accessibility: test the output, not the marketing

A builder can make accessible sites easy or very hard. With laws such as the European Accessibility Act and the risk of accessibility complaints, this is now a business issue, not just good practice. On your test page:

• Keyboard only. Tab through the page. Can you reach and operate the menu, dropdowns, tabs, accordions, sliders and popups? Is focus always visible? Can you close a popup with Escape? See fixing keyboard navigation and invisible focus.
• Semantics. In the Elements panel, check that headings are real heading tags in a logical order, buttons are <button> or links are <a> (not clickable <div> elements), and lists are lists.
• Control. Can you set the heading level independently of its look, add alt text, label icon buttons and form fields, and set a language?
• Automated check. Run an automated accessibility checker in the browser. It will not catch everything, but many failures in a default build are a warning sign.
• Contrast and motion. Can you meet contrast requirements with the default styles and respect reduced motion settings? See fixing color contrast.

7. Longevity and security

You are choosing a supplier for years. Look for evidence:

• Release history. Regular releases with clear changelogs, and timely compatibility with new WordPress and PHP versions. Check the changelog around recent major WordPress releases.
• Security record. Search public WordPress vulnerability databases for the product. Every popular tool has had vulnerabilities; what matters is how quickly they were fixed and how clearly they were disclosed. See what to do about a plugin vulnerability alert.
• Major rewrites. Has the product had a rewrite that forced migrations? How was it handled, and how long was the old version supported?
• Who is behind it. A company, a solo developer, a community? Has it been sold recently? Is there documentation and an active support channel?
• The block editor. Core WordPress has no license cost and a long future, but block themes and custom blocks have their own learning curve, and some designs need extra block plugins that carry the same questions as any other product.

8. Team fit and handover

Ask whether another competent designer could maintain the site if you were unavailable. A widely used tool with good documentation is easier to hand over than a niche one or a heavily customized setup only you understand. Consider your own team as well: standardizing on one or two options means faster builds, fewer surprises during updates and easier training. The guide to managing many client sites safely explains why a standard stack matters at scale.

A scoring sheet you can use

Score each option on your shortlist from 1 (poor) to 5 (strong) for each criterion, multiply by a weight that reflects your clients, and add up. The weights below are an example only; set your own.

Criterion	Example weight	Option A score	Option B score	Option C score
Handoff and client editing	3	[1 to 5]	[1 to 5]	[1 to 5]
License terms and transfer	2	[1 to 5]	[1 to 5]	[1 to 5]
Lock-in and exit cost	3	[1 to 5]	[1 to 5]	[1 to 5]
Performance	2	[1 to 5]	[1 to 5]	[1 to 5]
Accessibility of output	3	[1 to 5]	[1 to 5]	[1 to 5]
Longevity and security record	2	[1 to 5]	[1 to 5]	[1 to 5]
Team fit and build speed	2	[1 to 5]	[1 to 5]	[1 to 5]

The total matters less than the conversation it forces. If two options are close, prefer the one with the lower exit cost: it is the decision you can most easily undo.

Red flags

• The only way to keep the site working is to keep paying a license held in your name.
• Switching the builder off leaves nothing readable.
• Menus, tabs or popups cannot be used with a keyboard, and there is no setting to fix it.
• The changelog is sparse, or security fixes took a long time to arrive.
• You chose it because a demo looked impressive, not because you tested it.
• Nobody but you could maintain the site.

If none of that worked

If your shortlist all score badly on one criterion, decide which risk you can manage. Lock-in can be reduced by keeping content in ordinary pages and posts and using the builder for layout only. License risk can be reduced by putting licenses in the client’s name from the start. Performance can often be recovered with good images, fewer fonts and caching. Accessibility gaps in a builder’s own widgets are the hardest to fix, so weigh them heavily.

Whatever you choose, document it: the builder, version, license holder and renewal in the handoff document, and the reasons in your own notes. If the client later leaves, the client offboarding template covers transferring licenses and accounts cleanly. If you are taking over a site built with something you would not have chosen, start with the inherited site takeover playbook before deciding whether to keep it or plan an exit.