Here is how you know a WordPress build has failed: the marketing team has a private document explaining which pages they are allowed to touch. Everything else goes through a developer, a ticket and a two-week queue, for a change that ought to take four minutes.
Block themes were supposed to fix that. Mostly they have not, because they get built the way classic themes were built — by developers, for developers, with editors as an afterthought.
Freedom is not the goal
The instinct is to hand editors every block and control the editor offers. The result is a site that drifts within a month: nine shades of the brand colour, headings at sizes nobody chose, and spacing that changes page to page.
What editors actually want is not freedom, it is confidence — the certainty that the thing they publish at 4pm on a Friday will not look broken. That comes from constraint, not from options.
Lock the design system in theme.json
Define the palette, the type scale and the spacing scale once, and then disable custom values. If the brand has five colours, the colour picker should offer five colours and no eyedropper.
This feels restrictive during the build and is universally appreciated afterwards. Nobody has ever thanked a developer for the ability to set a heading in 43px. Turn off the blocks the site does not use, too — an editor scrolling past twelve irrelevant options is being slowed down by choices somebody else declined to make.
Ship patterns, not a blank canvas
The single highest-value thing you can hand a marketing team is a library of ready-made section patterns: a hero, a two-column feature, a testimonial band, a pricing table, a call to action. Named for what they do, not what they contain.
A new landing page then becomes assembly rather than construction, and it comes out looking like the rest of the site because it was made of the same parts. This is where block themes genuinely beat what came before, and it is the part most builds skip because it happens after the developer feels finished.
Block bloat is a real performance cost
The other reason to be selective is weight. Every block library you register loads CSS and JavaScript on the front end, whether or not a page uses those blocks, and the popular third-party collections are not shy about it.
Installing a 40-block library to get one accordion means every visitor downloads styling for 39 blocks nobody will ever see. Build the accordion, or pick a library that loads per-block. The difference on a content-heavy page is frequently several hundred kilobytes.
The same discipline applies to the patterns themselves. A pattern that hard-codes a full-width video background is a pattern that will be used on a landing page eventually, and it will be the slowest page on the site. Design patterns with a performance budget in mind, because whatever you ship will be used.
Someone has to own it after launch
Block themes drift. New page types get invented under deadline, somebody adds a one-off style, and eighteen months later the pattern library covers half of what the site actually does.
Name one person who reviews new patterns and folds recurring one-offs back into the library. It is perhaps an hour a month, and it is the difference between a system that compounds and a system that quietly reverts to everyone doing their own thing.
What to hand over at launch
A build is not done when the site goes live. It is done when the team can run it:
- A pattern library covering every section type the site actually uses.
- A locked palette, type scale and spacing scale, with custom values disabled.
- Editor roles that cannot reach template editing by accident.
- A ten-minute screen recording, not a forty-page PDF nobody opens.
- A staging environment where somebody can try something without consequences.
The test that matters
Two weeks after launch, ask a marketer to build a new landing page while you watch and say nothing. Every hesitation is a defect in the build, not a training gap.
The reward for getting this right is compounding rather than dramatic. Every campaign after launch costs a little less to produce, because the parts already exist and nobody is negotiating spacing. That is a boring benefit which quietly funds a great deal of marketing.
It helps to name the failure state out loud at kick-off: if the marketing team still needs a developer to publish a landing page six months from now, this build did not work, however good it looks. Teams that agree that definition early make different decisions about scope than teams that discover it afterwards.
Budget explicitly for the pattern library as a deliverable with its own line, rather than treating it as something that emerges from building the pages. Patterns extracted afterwards tend to encode the quirks of whichever page they came from, which is how libraries end up with three near-identical heroes nobody can choose between.
This also changes who should be in the room during the build. A marketer or content editor reviewing the pattern library at the halfway point will catch omissions no developer can anticipate, because they are the person who knows what next quarter's campaign needs. Bringing them in at handover is too late — by then the constraints are set and the only remaining option is a ticket.
The deeper point is that a WordPress build is not a website, it is a tool somebody else operates every week for years. Judging it on how it looks at launch is like judging a kitchen on the photographs rather than on cooking in it.
Ask the team six months later how often they needed a developer for something they expected to do themselves. That number is the honest measure of the build, and it is the one worth designing for from the first day rather than discovering afterwards.
That session tells you more than any acceptance checklist. It is also, in our experience, the moment most agencies discover their beautiful theme is unusable. Good WordPress development is judged months later, by whether anyone needed to raise a ticket. If your team is routing content changes through developers, get in touch.
