Handing Over a Bricks Site: White-Labelling and Client Permissions

Handover is where the money on a project is made or lost. The build is quoted and finite; what follows is open-ended, and the difference between a site that generates one support email a year and one that generates ten is decided by choices made in the last week of the project.

This covers the Bricks-specific mechanics and the two commercial questions that get skipped: who owns the licence, and who is liable for support after the invoice is paid.

Decide the access model before you configure anything

Three positions, and picking one deliberately prevents most of what follows.

1. No builder access. Content lives in custom fields, the client works in the normal WordPress admin, and they never see Bricks. The right default for most client sites.
2. Content-only builder access. The client can open the builder and edit text and images but cannot change structure, add elements or touch templates. Suitable for a marketing team that publishes regularly.
3. Full access. They can do what you can do. Appropriate when the client has an in-house developer, and a liability in every other case.

The pressure to grant more access than is wise usually comes at the end of a project, from a client who wants to feel in control. It is worth having the conversation earlier, framed around what happens when something breaks and who pays to fix it.

If you are using the field-based approach, the template architecture that makes it work is a build-time decision about field structure rather than a permissions setting.

The role manager

Bricks includes a role manager that controls, per WordPress role, who can open the builder and what they can do inside it. This is where the access model you chose becomes configuration.

Work role by role rather than user by user. Editors and administrators need different permissions, and a client organisation will add and remove people without telling you. Permissions attached to a role survive staff turnover; permissions attached to a named user do not.

The settings worth restricting on almost every client build are access to the builder itself, the ability to edit templates, and access to the theme and builder settings screens. Content editing is what you are leaving open; everything structural is what you are closing.

Test it properly. Create a real user at the client’s intended role, log in as them in a private window, and try to break things. Checking the settings screen is not testing; the settings screen tells you what you intended, not what is true.

Element-level permissions and template locking

Beyond role-level access, Bricks lets you go finer: restricting which elements a role can use, and locking parts of a structure so they cannot be moved or deleted.

Use this to protect the parts of a layout that carry the design. A client adding a paragraph inside a content area is fine and is the point. A client dragging that paragraph out of its container and into the header is the scenario locking exists for.

Header, footer and any global template deserve the strictest treatment available, because a mistake there is site-wide and often invisible from the page the client was editing. The most common support call in this category is not a client reporting that they broke the header; it is a customer reporting that the phone number is missing from every page and nobody knowing why.

Keep the restrictions proportionate. Locking everything produces a client who cannot do the one thing you promised they could, and then emails you to do it.

Documentation that gets read

A forty-page PDF is a document nobody opens. What works is short, specific and located where the task happens.

• One page, task-based. How to add a team member. How to change the homepage banner. How to publish a post. Named after what the client wants to do, not after the feature.
• Field instructions in the admin. The most effective documentation is a sentence under the field, visible at the moment of editing.
• A short screen recording per task. Two minutes each, and far more likely to be watched than read.
• What not to touch, and who to call. One paragraph, in writing, including what is outside the retainer.

Write it during the build rather than after. Documentation produced at the end is written from memory, by someone who wants the project finished, and it shows.

Licence transfer at contract end

This is the commercial question that gets deferred until it is a problem, and it has only a few sensible answers.

If you retain maintenance, keep the licence on your account and price it into the retainer. It is simpler, you control renewal, and you find out about expiry before the client does. Divide the annual cost by the number of sites it covers and put the result in the monthly fee.

If the client is taking the site in-house or moving to another agency, transfer the licence or have them buy their own before you disengage, and record the date it changed hands. What you must not do is leave a licence on your account attached to a site you no longer maintain: you carry the cost, you carry the renewal admin, and you get the phone call when it lapses.

Either way it belongs in the contract at the start, not in an email at the end. The wider question of how to price tooling across a portfolio, including which licences to own and which to bill through, is worked through in our builder licensing and ROI comparison.

Support liability after handover

The last thing to settle, and the one that quietly costs the most.

Write down what is covered and what is not. Updates, backups and uptime are maintenance. Content changes, new sections and design revisions are work. A client who believes their monthly fee includes unlimited small edits is not being unreasonable if nobody told them otherwise.

Be specific about the boundary that matters on a builder-based site: if the client has builder access and breaks a template, is fixing it maintenance or billable? Decide now, in writing. Answering it for free the first time sets the precedent for every time after.

Where a client has no builder access at all, this problem mostly disappears, which is the practical argument for the field-based model over any permissions configuration. The best permission system is not needing one.

Frequently Asked Questions

Can you white-label Bricks for a client?

You can remove or restrict most of what a client sees of the builder through the role manager and by keeping them out of the builder entirely. Treat full removal of vendor branding as something to verify against the current licence terms rather than assume, because white-labelling permissions differ by vendor and change between versions.

Who should own the Bricks licence after handover?

Whoever will still be responsible for the site in two years. If you retain maintenance, keep it on your account and bill it through the retainer. If the client is leaving your care, transfer it or have them buy their own, and put the date in writing. The failure mode is a licence on your account for a site you no longer touch.

What happens when a Bricks licence expires?

The site keeps working. What stops is updates and support, which on a builder that is also the theme is a slow-building security and compatibility problem rather than an immediate outage. Treat a lapsed licence on a live client site as an incident to resolve, not an admin note.

Should clients have access to the Bricks builder at all?

Usually not. If content lives in custom fields, the client edits fields in the WordPress admin and never opens the builder, which removes the entire category of layout damage. Give builder access only where the client genuinely needs to create new page structures and has someone competent to do it.

How do I stop a client breaking the header and footer?

Keep template editing out of their role entirely. Header, footer and global templates should be editable by you and nobody else, because a single accidental change there affects every page on the site rather than one, and it is the change most likely to go unnoticed until a customer reports it.

Choose the access model first, configure roles to match, lock the global templates, document by task, and settle licence ownership and support scope in the contract rather than in an email eighteen months later. The builder mechanics are the easy half. The rest is what determines whether the project was profitable. The wider Bricks decision is covered in our Bricks vs Oxygen Builder comparison.