The moment I knew Kadence had to go was not dramatic. I was in a conversation with Claude, designing new hub pages for IrelandExplore.com, and I found myself saying: "Okay, to build this you need to create a row layout in Kadence where you set the columns to three, then add an info box block in each column, then configure the heading size to..."
I stopped. I was translating design intent into page builder instructions. I was not designing. I was configuring. And I had been doing it with Kadence for two years (and GeneratePress for 3 years before that) across eight properties without questioning whether this was the right layer of abstraction.
The dependency audit
An audit of one of my smaller sites, IrelandExplore, revealed 361 Kadence block instances across 57 posts and pages. Fifteen different block types, all proprietary. Every row layout, every styled heading, every button, every gallery was Kadence markup that no other system could read.
All 15 block types mapped to just 6 or 7 native HTML and CSS components. The proprietary layer was adding complexity without adding capability.
If Kadence changed their block structure in an update, there was a risk that my automated pipelines would break. If I wanted Claude Code to generate or modify page templates, it had to work around Kadence's custom syntax rather than using clean, standard HTML. It struggled. I struggled. We all struggled. Every property was locked to a single vendor's interpretation of how a row layout should be marked up.
On the third round of trying to automate the addition of a simple card layout, where Kadence was overriding some custom CSS from Claude Code, I knew I had to do one of two things: suck up Wordpress + Kadence as my stack, or look into cleaner, lighter solutions for my content management systems. But can you so easily leave the closed loop of Wordpress. To do so means stepping into your vibe coding era and rethinking the biblical truth that design must fit the block builder.
What "design by conversation" actually means
The alternative turned out to be simpler than I expected. Instead of configuring a page builder, I describe what I want to an AI assistant and it produces clean HTML and CSS. Not Kadence markup. Not WordPress block syntax. Just the web standards that have worked for thirty years.
A hub page for IrelandExplore that took an afternoon of clicking through Kadence settings now takes a conversation. I describe the layout, the card structure, the content hierarchy. The AI produces a working prototype. I refine it. The output is portable, readable HTML with CSS custom properties that any developer, any AI tool, or any future system can understand instantly.
The design system for each property lives in a set of CSS variables. IrelandExplore uses peat browns and gorse yellows drawn from the Irish landscape. Vatican Bulletin uses liturgical golds on linen. PatrickHughes.ai uses a dark technical palette with green accents. The variables change, the component structure stays the same.
The real cost of page builders
Page builders solve a genuine problem: they let non-developers create visually complex pages. I am not dismissing that. When I started Planet Patrick in 2006, after learning to code HTML in the year 2000 ("Hello, World!"), Wordpress was a complete godsend and learning Divi, Elementor, GeneratePress and Kadence were steps into design skills. Kadence was the right tool. I knew basic CSS, but I didn't want to hand-code it. I just needed something that worked.
The problem is what happens two years later when you have built eight sites and started automating content production. The page builder becomes the bottleneck, not the enabler. Your automation pipeline generates a perfectly structured blog post, and then you have to manually configure Kadence blocks to display it. Your AI assistant can write and modify any standard HTML, but it cannot reliably manipulate proprietary block markup.
As a rough estimate, I was spending 40% of my time wrangling Kadence configuration vs actual content creation. Oh, why doesn't that work like that? Generateblocks does. Hmm, okay, that's a Pro feature. Oh, they've got an AI tool. Nope, that doesn't help. Let me look up the forum / ask a question. And heaven knows, I love a side quest. But side quests kill your concentration.
The hosting cost matters too. Each WordPress site needs PHP, a database, a server. Multiply that across eight properties and you are paying serious money to host what is essentially a collection of articles. The Astro alternative serves the same content as static files on Cloudflare's free tier.
The migration is not a search and replace
I will be honest about this: stripping Kadence from a live site with 361 block instances is not trivial. The first attempt on IrelandExplore surfaced edge cases that a simple find-and-replace could not handle. Nested columns inside row layouts, gallery blocks with custom aspect ratios, buttons with conditional styling.
The approach that worked was building on a clean-slate property first. Vatican Bulletin was a new site with only a handful of posts and no audience at risk. Every lesson learned there gets applied back to the established properties with confidence. I have built my own proof of concepts in a safe space and have started rolling it towards my bigger properties a little less nervously.
The build order matters. Start with the site that has the least to lose. Prove the architecture. Then migrate the properties that generate traffic and revenue, armed with the knowledge of what breaks and how to fix it.
Where this ends up
The endgame is not "a better WordPress theme." The endgame is a content architecture where my custom CMS handles creation, Supabase stores everything, Astro renders static frontends per property, and Cloudflare serves them for nearly nothing. The hosting bill drops from the hundreds of dollars I was paying annually for hosting and the Kadence Pro tools, to essentially domain renewals. The codebase is portable. The design is mine. Plus one my system is set up, I get more time to create instead of wrangle.
Kadence was fine at one point. It solved a real problem. But the moment you start building automation systems that generate content programmatically, the page builder becomes the bottleneck, not the enabler. Rip it out. Build clean. Move on.
Am I a traditional developer? No. But I gained enough skills to direct the development that Claude Code and other automation tools can do. And I know what I want to achieve. If you're at the point of taking more control of your own creativity and content, you're in the right place.