For years, the WordPress page-builder conversation was simple: Elementor or Divi for speed, custom code for control. That line is blurring fast in 2026. Full Site Editing has matured into something genuinely usable, and I’m seeing more client briefs specifically ask for “no Elementor” — often because a previous site became slow, fragile, or impossible to hand off to a new developer.

Custom Gutenberg blocks are the reason that request is now realistic instead of wishful thinking.

What changed between 2022 and now

Early custom block development meant wrestling with a React build pipeline just to output a hero section. It worked, but it wasn’t fast enough to justify over a page builder for most client budgets. That’s no longer true. The block tooling matured, block patterns became genuinely reusable, and the editing experience for clients closed the gap with what they were used to in Elementor — without dragging along a plugin’s entire runtime on the front end.

The practical result: a custom “Services Grid” block can now be built, styled, and shipped in less time than it takes to configure the equivalent section in a page builder with global styles, responsive breakpoints, and animation settings.

Why clients actually prefer it once they try it

  • Nothing to break. There’s no builder plugin update that can shift every page’s layout overnight.
  • Faster sites by default. A custom block ships only the CSS and JS it needs — not an entire builder framework loaded on every page, used or not.
  • A real content model. Blocks can expose exactly the fields a client needs (a headline, three feature cards, one image) and nothing else, which means less chance of them accidentally breaking a layout.
  • It survives a developer handoff. Native blocks are just WordPress. The next developer doesn’t need to learn a third-party builder’s quirks to maintain the site.

The goal was never to make editing harder — it was to make the wrong kind of editing impossible.

Where page builders still win

I won’t pretend custom blocks are the right call for everyone. If a client genuinely wants to build entire pages themselves with total layout freedom, or the project timeline can’t absorb any custom development time at all, a builder is still the faster path to launch. The trade-off is what it’s always been: more freedom now, more risk later.

A quick way to decide

Ask one question before the kickoff call ends: who is going to maintain this site in two years? If the answer is “whoever we hire next,” custom blocks (or a hand-coded theme entirely) tend to age far better than a builder-heavy build that only the original developer really understands.

What this looks like in practice

On recent projects, this has meant building a small internal block library per client — a hero block, a stats block, a testimonial block, a CTA block — each with just enough ACF-powered fields to stay flexible without becoming a second page builder in disguise. It’s more upfront planning than dropping in a builder plugin, but it pays off the moment the client wants to add a tenth page without calling for help.

If your last WordPress site started feeling slower with every plugin update, this is usually why — and it’s exactly the kind of rebuild I take on.