The problem we keep seeing is not that marketing teams are slow.
The problem is that their tools force them to be.
On almost every engagement we take on involving a WordPress site that’s been running for more
than two years, we find the same pattern: a marketing team that is genuinely capable, sitting behind
a bottleneck they didn’t create. Every page update goes through engineering. Every new landing
page requires a ticket. Every campaign launch is conditional on developer availability.
This is not a people problem. It is a systems problem. And it has a direct, measurable cost.
—
THE NUMBERS THAT MADE US BUILD DIFFERENTLY
On a recent client engagement, marketing was filing 40 to 50 tickets against engineering per quarter.
Each ticket took an average of two hours of senior developer time to resolve. That is 80 to 100
engineering hours per quarter — roughly two full weeks of a senior engineer’s capacity — going to
content changes.
None of those changes required engineering expertise. They required an engineer because the
system wasn’t built for anyone else.
The same client, after we rebuilt their site on a Gutenberg block system, dropped that ticket volume
by 91% in the first quarter post-launch. Page-build time went from four days — ticket filing, sprint
queue, design review, QA — to approximately five hours of independent content work.
The engineers got their time back. Marketing got their autonomy. Both teams became better at their
actual jobs.
—
WHAT A GUTENBERG BLOCK SYSTEM ACTUALLY IS
When most people say “Gutenberg blocks,” they mean the built-in WordPress blocks: paragraphs,
headings, images, columns. These are fine for simple sites. They are not what we are talking about.
A custom Gutenberg block system is a library of purpose-built blocks, each one designed around a
specific content pattern your team actually uses. A hero block. A feature comparison block. A
testimonial carousel. A pricing table. A code snippet display. Whatever your site requires.
The difference between a built-in block and a custom block is control. With a built-in block, a content
editor has access to every typographic option, every colour, every spacing value. This sounds like
freedom. In practice, it means every page looks slightly different, and every off-brand result is one
careless click away.
A custom block exposes only what the editor needs to control: the headline text, the body copy, the
image, the CTA label. Everything else — the layout, the typefaces, the spacing, the colours — is
encoded in the block itself. The editor cannot accidentally produce an off-brand page. The design
system cannot be broken by a non-developer. That constraint is the feature.
—
HOW WE BUILD THEM
We use @wordpress/scripts as the build toolchain, TypeScript for the editor interface, and PHP for
the server-side render. Each block is registered as a standalone module with its own edit
component, save component, and attributes schema.
The attribute schema is where the design system lives. A colour attribute that accepts only four
values will only show four options in the editor. A layout attribute with a set of predefined options will
render a select input, not a freeform field. The block’s visual output is a pure function of its attributes
— which means any content editor can preview exactly what they’ll get before they publish.
Documentation is built in parallel, not as an afterthought. We write one reference page per block: a
screenshot of the block in use, a description of every editable field and what it controls, and two or
three example use cases. This document becomes the marketing team’s operating manual. In our
experience, teams who have a well-written block reference doc are still using it — and still
referencing it for new hire onboarding — eighteen months after the engagement ends.
—
THE HANDOFF THAT ACTUALLY STICKS
We’ve seen agencies deliver block libraries and then spend two weeks explaining them over Slack
because the handoff was a 20-minute walkthrough on a Friday.
Our handoff has two components: a recorded training session and a written reference document.
The training session runs two hours and is recorded end-to-end. It covers the full page-building
workflow, every block category, and the most common mistakes to avoid. It lives in Loom. New team
members can watch it on their first day and be productive within a morning.
The reference document lives in Notion, structured so that any block can be found in under ten
seconds. It is updated if we add blocks during a maintenance engagement. It is the source of truth.
The measure of a good handoff is not whether the client can use the system on the day we leave. It
is whether they can still use it — and teach others to use it — twelve months later. That is what we
build for.
—
WHEN THIS APPROACH IS RIGHT (AND WHEN IT ISN’T)
A custom block library is the right investment when a marketing team publishes frequently, needs to
create diverse page types, and is currently dependent on engineering for content changes.
It is overkill for a five-page brochure site with no content calendar. A well-configured theme and
sensible editor settings are enough for that.
The signal we look for: if your marketing team files more than five tickets per quarter against
engineering for content-related changes, a custom block system will pay for itself in the first six
months. Usually sooner.
If you think your site might be at that point, we’re happy to review it. The first call is 30 minutes and it
costs nothing.