Why We Don’t Use Block Libraries at Equalize Digital

In a conversation on X, Matt Cromwell asked me why we wouldn’t rebuild our company website with Kadence WP or similar available tools.

Given how much Kadence has been focusing on accessibility and how far ahead they are than many other page builders in terms of accessibility, this is a fair question. He had a follow-up comment that he thought going full custom was slowing us down:

Honestly, that's a weird choice. Not about Kadence at all (I'm officially unbiased now)… Why not just build a flat file custom site with Loveable? If you can't build the perfectly accessible site with common WP blocks, only your own custom blocks, then why keep building in WP!?…

— :Cromwell: (@learnwithmattc) January 16, 2026

I started replying in X and realized it was long enough for a blog post… so here we are: a post about my thoughts on block libraries and page builders, and why we generally don’t use them at Equalize Digital (my company).

First, a Clarification…

We use and love core blocks! I’m all about core blocks, and if a website can be built with only WordPress core blocks, that is the best way to build.

This website is, in fact, built on the core Twenty Twenty-Four theme and uses only core blocks. When I launched it, I wrote on our company blog about how I rebuilt my site in 2 days and eliminated thousands of accessibility issues simply by moving away from my previous “off-the-shelf” premium theme and using a core WordPress theme and blocks instead.

Not only did switching themes help with accessibility, but it also significantly improved load times and performance. The coolest thing about using a core theme and only core blocks was that, when I needed to troubleshoot something on the site, I deactivated all my plugins, and my home page looked identical to how it looks with all the plugins active. You pretty much never see that.

So yes, we use core blocks. We just don’t use block libraries. If there’s something we need that core blocks can’t handle (say, tabs), our approach at Equalize Digital is not to look for a plugin to add that functionality; instead, we would code a custom block or a custom ACF block.

Why We Don’t Use WordPress Block Libraries… Anymore.

We used to use block libraries.

We were early adopters of building hybrid websites with the block editor. We were building websites for clients with blocks pretty much as soon as it launched in 2018.

At that point, we used block libraries available via WordPress.org, because, to be honest, we didn’t know how to build custom blocks, and core blocks were incredibly limited (still are).

For years, we sped up our website builds and added cool features without code by using block libraries (and occasionally page builders like Elementor). Back then, most of our revenue came from small businesses or nonprofits, and the goal was to build websites as fast as possible, then maintain them on monthly retainers. Block libraries helped make that possible and allowed us to build nice-looking websites for under $20k.

So what changed?

A few devs ruined it for everyone.

Here’s the short story, without naming names:

• Library A was bought by a hosting company, which then deprecated it and wanted people to switch to a renamed version that was basically the same, but used different class names, which would have required us to edit all our custom styles.
• Library B changed its CSS class names during an update, breaking all our custom styles.
• Library C, on update, changed the loading order of its stylesheet so it loaded last, which meant it loaded after our theme stylesheet and thus overrode all our custom styles.
• Library D was abandoned and then removed from dot org due to security issues, which we had to patch in the version on our website because it was used in too many places to remove and was no longer supported.

There are amazing block libraries that do what they do really well, and I put Kadence up there. But basically, A, B, C, and D ruined it for everyone.

No one wants to test a plugin update and realize they have to redo a ton of work or spend hours on support with the plugin dev before they can push updates live — especially for stupid reasons like CSS class name changes that break backward compatibility.

To put it frankly, after those experiences, I don’t trust third-party devs who know nothing about my website or my priorities to not F my website up. 😂

Enterprise websites require a lot more attention to detail.

The other factor in our decision not to use block libraries is that, over the years, we shifted from building small-business websites to enterprise websites and web applications for government, higher education, large publishers, health care clients, and the like. Projects were no longer $15k; instead, they were $60k–$140k+—essentially enterprise WordPress.

In the land of enterprise WordPress, where accessibility, security, legal compliance, performance, and conversion optimization really matter, you have to be a lot more picky about what goes on the site. Every plugin introduces risk: extra code to monitor, potential accessibility barriers, new security risks, performance overhead, and UX decisions you don’t fully control. At scale, those trade-offs compound quickly, so the question isn’t just “Does this plugin help us build faster?” but “Does it meet our standards, integrate cleanly with our stack, and help our clients meet their legal, business, and user experience goals over the long term?”

Increasingly, block libraries never felt worth the trade-offs or loss of control, especially because they are the foundation of the website.

If something goes wrong with a block library, it can require significant rework.

When you build your website with a block library, you use components that are central to how your pages look and are interacted with. Things like accordions, tabs, layout blocks like columns or grids, maybe even basic components like button links, headings, or image galleries are controlled by the library. These components are typically used everywhere on the website.

If that library is abandoned or you decide you don’t want to use it anymore, you’re now signed up for huge amounts of work to remove or replace the components across potentially hundreds or more pages. The entire site may need to be rebuilt even if you didn’t change the theme. (This is no different from if you decided to switch away from a page builder.)

If you, instead, build your pages with only core blocks or custom/ACF blocks, there’s less inherent risk of needing to rebuild because:

1. Those blocks are not controlled by a company that has totally different priorities than you do.
2. Even if you rebuild, it’s easy to migrate your custom block code between themes or restyle core blocks in a new theme.

Not wanting to rebuild lots of old content during your next redesign is one of the reasons I advocate for only using core blocks in blog posts, and definitely never building them with a page builder. I’d also say it’s safest to make rules like only using core container blocks (columns, grids, etc.).

There is a Line

I’m not saying there is no place for block libraries. I’m also not saying that everything on websites should be custom.

Some things are not worth maintaining.

For certain complex functionalities, such as forms, e-commerce, CRM, payment gateway, or API integrations, etc., it makes total sense to buy a plugin rather than maintain them yourself.

Features that are deeply intertwined with security or legal compliance, or that add mission-critical platform functionality to your website, are typically better achieved by buying a plugin rather than custom coding. Companies (or individuals) who work on these plugins full-time will be much more in tune with ongoing platform changes, and keeping up with all of that in custom code is rarely a good use of your time or budget.

These plugins benefit from dedicated development teams, regular updates, broader real-world testing, and community feedback. In these cases, the website is far more likely to remain stable, secure, and compatible over time with the addition of a third-party plugin rather than with something coded once during the initial build and never updated.

The thing is, block libraries don’t pass this test. If your tab block is coded once and doesn’t get updated, it won’t break your website. If you do need to make slight padding or margin changes or add the ability for a different design inside the tabs, that’s trivial work. It’s not the same as maintaining compatibility with the Stripe checkout API.

The best use case: non-mission-critical websites.

For personal or business websites that are not mission-critical (where a bit of downtime or layout oddities after an update don’t truly matter, or sales aren’t happening on the site), an off-the-shelf theme, block library, or page builder is just fine.

Most small, local businesses don’t need a fancy custom design. They need something that looks generally professional, is findable in search, and allows people to get key information about their business and how to contact them. This is especially true for companies that get most of their business via Google Maps or review sites like Yelp. Think websites for restaurants, hair salons, churches, single-location brick and mortar businesses, or small nonprofits with very tiny (or essentially zero) budgets.

These websites are ideal use cases for a page builder or a block library. They typically don’t have a large budget for either the initial build or ongoing maintenance, and so custom isn’t possible. In many cases, the people building the sites may not even be developers. They also don’t need the same attention to detail to achieve their goals.

If custom isn’t possible (or necessary) and a desired feature doesn’t exist in WordPress core, then a block library can help fill the gap. I say this to make it clear that I don’t think block libraries are all bad. Block libraries play an important role in the WordPress ecosystem. If I were building these types of websites, I would probably be using a block library like Kadence.

How about the Equalize Digital website?

So why don’t we use block libraries at Equalize Digital?

We’re not an enterprise company yet (working on it!), but we treat our website like an enterprise site because we need it to always be available for sales. We don’t run autoupdates, and we question everything we put on the site.

I really don’t want my website to look “off” or broken. We sell to enterprise organizations, and we need to communicate trust. Increasingly, I care deeply about performance optimization because we make sales on our website every day.

I want our site to look polished, not have increased load times due to bloat from a library loading code on every page for blocks we’ll never use, and to funnel people through to a checkout with as little maintenance on our end as possible.

We’re a small team doing a lot of things. I don’t want to test updates on staging and see new “features” added that I didn’t ask for or that require us to go back to the dev for support before we can run updates on live – all things we’ve seen with past block libraries.

Does it slow us down during the initial build to have to create blocks from scratch? Yes.

But in the long run, it speeds things up because it gives us fewer things to test during routine updates and a lot more peace of mind that things will stay as we have built them, without surprises.