Bricks Builder Review 2026: Still My WordPress Pick, After Leaving WordPress

I moved this agency site off Oxygen and onto Bricks in 2024. Then I moved it off WordPress altogether. It runs on Next.js and Directus now, and I wrote about the reasons in why I stopped using WordPress after 6 years.

So this is an odd review. It comes from someone who left the platform Bricks lives on, and still thinks Bricks is the best way to build on that platform.

Both of those are true at the same time. When a client project does belong on WordPress, the Bricks builder for WordPress is still the first thing I'd install. This review covers why, what Bricks has shipped since I last built with it day to day, and the one thing on the pricing page that the old version of this post got wrong.

What Bricks builder is, and why I switched to it in the first place

Over the years I ran client sites on WPBakery, Elementor, LiveCanvas and Oxygen. In 2018 I moved to Oxygen for the clean code. In 2024 I moved to Bricks, because it kept Oxygen's lightweight output and added a builder I did not want to throw my laptop across the room over.

The reason it works is structural. Bricks is a theme and a visual builder in one. With Elementor or Divi you install a theme and bolt a builder on top, and the two argue about markup and CSS forever. With Bricks the builder is the theme, so the output is one predictable layer instead of two fighting ones.

That mattered to me once I started caring about SEO and Core Web Vitals more than about how fast I could drag a box onto a page. If you want the wider field, I put it up against the others in my comparison of the top WordPress page builders. This piece is the deep dive on Bricks.

Where I stand on WordPress now, and where Bricks fits

My cutoff is written down in should I still use WordPress in 2026: WordPress goes on the table when the site needs software that WordPress already solved, like a WooCommerce store or a team of editors with roles and an approval chain.

If a site only needs pages, I build it in Astro, and I explain that decision in how I choose between WordPress, Next.js and Astro.

Bricks lives inside that first group. When WordPress is the right answer, Bricks makes the good version of it. It does not fix WordPress being WordPress. The plugin security treadmill and the governance mess I wrote about are still there underneath, no matter how clean your builder output is.

One Bricks project I can point to is a client site that pulled job listings from Recruitee. I wrote a custom plugin that hooked into Bricks form submissions and pushed applications, CV uploads included, straight into the client's Recruitee pipeline. It ran for over a year without drama, and when the project ended I open-sourced the Bricks Recruitee plugin. That is the kind of job where Bricks earns its place: WordPress doing real work, with a builder that stays out of the developer's way.

What Bricks shipped while I was building elsewhere

I need to be upfront about this section. Since I moved my own work off WordPress, I have followed Bricks mostly through its changelog, not inside the builder. So everything below is "Bricks shipped X in version Y", not "I used X on a client site."

Bricks 2.0 (July 2025) went after the interface. The Command Palette (CMD or CTRL + K) lets you jump to pages, search post types and insert elements without the mouse. The Element Manager lets you disable elements globally so the insert list is not a wall of things you never click. There are over 50 granular builder permissions, so a client's marketing person can edit content without touching the layout. Cascade layers are on by default, which isolates theme, user and component styles so overrides stop fighting each other. The 2.0 release also patched a SQL injection vulnerability (CVE-2025-6495) in earlier versions, so if you are sitting on an old 1.x install, that alone is a reason to update.

Bricks 2.1 (October 2025) turned queries into a real system: a global Query Manager so you define a query once and reuse it, querying data from external APIs, and creating and updating posts from frontend forms. It also added Wireframes and Design Sets, and the option to register Bricks components as Gutenberg blocks.

Bricks 2.2 (February 2026) is the one I would have loved during my Bricks years. A unified Style Manager for design tokens, a Color Manager with dark mode variants and shade generation, generators for fluid typography and spacing scales, and a CSS framework importer. Components got slots, style variants and nested property bindings.

Bricks 2.3 (March 2026) added pasting HTML and CSS straight into the builder, which Bricks then converts into native elements, classes and variables. It also upgraded the query filter controls: searchable multi-selects via Choices.js, range filters with decimals, datepicker format controls and properly stylable radios and checkboxes.

Bricks 2.4 and the AI abilities

The current major release is Bricks 2.4, out September 16, 2026, with 2.4.2 following on September 28. The headline is what Bricks calls AI-assisted site editing.

Under Bricks > AI you connect a compatible AI client, and the release notes name Codex, Claude and Copilot. The client can then create pages, edit existing content and manage the design system. The abilities cover pages, elements, templates, components, global classes, variables, color palettes, queries, navigation menus, WooCommerce setup and import/export. Each ability has its own on/off control. Letting the agent execute PHP is a separate switch that only turns on with a constant in wp-config.php, and Bricks positions it for development environments.

I have not connected an agent to a Bricks site, so take this as reasoning rather than a test. I use Claude Code every day, and I was openly grumpy about WordPress shipping AI connectors before it ships caching. The Bricks approach sits better with me. It is scoped to the builder's own objects, you can turn individual abilities off, and the dangerous one is opt-in through a constant rather than a checkbox. Whether an agent produces Bricks layouts you would hand to a client is the part I cannot vouch for yet.

The rest of 2.4 is less flashy and probably more useful day to day. Global import and export moves a whole design system (theme styles, classes, variables, palettes, breakpoints, components, templates, fonts, icons) between sites as a ZIP, and leaves out API keys and code execution settings. Remote Components pulls components from another Bricks install with their dependencies. You can rearrange the builder panels and save the layout as a profile per user or role. And WooCommerce got a setup wizard that creates Cart, Checkout, My Account, Shop and Single Product structures, plus experimental v2 elements and a Mini Cart Builder.

Performance is still the reason Bricks wins

The original version of this review carried a Bricks-versus-the-rest benchmark. I did not rerun it on 2.4, so read it as a historical snapshot of the gap, not a fresh measurement:

Metric	Bricks	Elementor Pro	Divi	Visual Composer
PageSpeed mobile	98	75	64	58
Pingdom result	98	79	82	79
HTTP requests	6	34	23	36
Page size	0.19 MB	1.7 MB	1.5 MB	1.1 MB

Six HTTP requests against thirty-plus is a different category of site. Bricks runs on Vue 3, ships lightweight markup, and gives you a lazy asset loader, native lazy loading and the option to switch off default WordPress scripts you do not use. The 2.4 notes add smaller wins like less font lookup overhead and instant navigation inside the builder turned on by default.

The builder is not a performance plugin, though. WordPress still ships with no page caching, so you still need a caching layer and decent hosting. I go through how I test all of this in my website speed testing guide, and the caching and hosting halves in my FlyingPress review and Cloudways hosting review. Fast markup plus good hosting is the combination. Bricks gives you the first half.

Building for clients: components, queries and WooCommerce

What made Bricks worth it on real projects was the dynamic and reusable side, and that is where most of the 2.x work went.

Components used to be the weak spot. Now you can nest them, give them style variants, add slots for custom content, and register them as Gutenberg blocks so a content editor drops them into a post without opening the builder. For client handoff that is the setup I always wanted: I build the design system, they write the content.

On the shop side, the WooCommerce builder covers product, cart and checkout pages with the same drag-and-drop. 2.0 added native variation swatches for color, image and text, plus interaction triggers for cart events like "added to cart" and "coupon applied." With the 2.4 setup wizard and mini cart builder, a full custom storefront needs fewer add-ons than it used to. Given that WooCommerce is one of the main reasons I would still say yes to WordPress, this is the part of Bricks I would look at hardest.

Where Bricks still frustrates me

The template ecosystem is still thin. Wireframes and Design Sets help, and 2.4's import/export and remote components make it easier to carry your own starter kit between sites. But if you want to buy a finished theme and tweak it for an afternoon, this is not that ecosystem. Bricks rewards people who build from a blank canvas.

The learning curve got steeper as the tool got more powerful. The Style Manager, design tokens, component slots and global queries are a real mental model. If you have never touched CSS variables, your first Bricks build will be slow. Someone coming from Elementor's "everything is a widget with a hundred toggles" world has to unlearn some habits.

And when you cannot find an element, you build one. If you know PHP, HTML, CSS and JavaScript, you write a custom element once and use it on every site. That escape hatch is why I never felt locked in, and it fits my instinct of fewer plugins and more control. If that is yours too, you will like my list of WordPress plugins you can replace with a few lines of PHP.

Pricing: the part the old review got wrong

The earlier version of this post said Bricks was a one-off payment with tiers up to a thousand sites. That is not what bricksbuilder.io shows today. The current pricing page lists four plans:

Plan	Price	Sites
Starter	$79 per year	1
Business	$149 per year	3
Agency	$249 per year	Unlimited
Ultimate Lifetime	$599 once	Unlimited

Every plan gets the full feature set, there is a 60-day money-back guarantee, and local and staging sites do not count against the limit. The yearly plans renew until you cancel. The lifetime plan is still pay once, with all future updates and support.

I did not check when the structure changed, so I will not guess at it. For an agency that keeps building on WordPress, the math points at Lifetime: after about two and a half years, the Agency plan has cost more than Lifetime. For a single business site, the $79 Starter plan gets you the same features as the $599 one.

Would I recommend Bricks builder in 2026?

Yes, with a narrower scope than the old version of this review had.

If your project belongs on WordPress, say a WooCommerce shop or a site run by a team of editors, build it with Bricks. The output is lean, and the design token and component system has turned it into a proper design tool. I would pick it over Elementor or Divi without much thought.

If your site is mostly pages, I would not start with WordPress at all, and a great builder does not change that. I have not tried the AI abilities, and I do not know yet whether they make Bricks a better fit for people who never want to touch CSS. That is the open question I will be watching.

If you are trying to work out which side of that line your project sits on, that is literally my job. Come say hi at wunderlandmedia.com and tell me what you are building.