Why we stopped building client sites on page builders

Page builders are genuinely fast for shipping the first version of a site, and we used them regularly in our earlier years for exactly that reason. What they're slow at is almost everything that happens after launch: a second developer inheriting a maze of nested sections and proprietary shortcodes, a Core Web Vitals fix that turns out to require removing a plugin the whole page layout secretly depends on, a routine redesign that turns into a full rebuild because nothing in the original build was actually componentized in a reusable way.

We stopped defaulting to them for most client work for exactly that reason, after watching too many of these problems show up on sites we didn't build but got asked to fix. The pattern was consistent enough across different builders and different clients that it stopped looking like bad luck and started looking like a structural property of the category.

Most page builders generate markup that only makes sense inside their own editor, full of framework-specific classes and structural wrappers that exist to serve the tool, not the page. Move to a different platform, or even hand the project to a different developer using the same platform, and you're not migrating a site, you're effectively rebuilding one from screenshots and memory.

A client should own something genuinely portable at the end of an engagement: code a competent developer anywhere can open, understand, and extend without first learning a proprietary tool's internal conventions. That's a basic form of ownership we think every client is entitled to, and it's one page builders structurally can't offer, however good their marketing about "exporting your code" sounds on the sales page.

We've audited page-builder sites where the actual visible content, text and images, weighs a reasonable 200KB, and the builder's own runtime JavaScript adds another 1.5MB before anything meaningful even renders. That's not a content problem you can fix with better image compression or a faster hosting plan. It's an architectural ceiling baked into the tool itself.

This is the actual reason behind a lot of "we tried everything and it's still slow" performance complaints we hear from prospective clients. The team genuinely did try everything within the platform's control. The platform itself was the ceiling, and no amount of content-level optimization was ever going to get underneath it, because the runtime overhead exists regardless of what you build on top of it.

For most marketing sites now, that's Next.js paired with a component library the client's own marketing team can extend and rearrange without touching code, or WordPress when a client's internal team is already fluent in it and the site doesn't need heavy custom interaction beyond what standard blocks and well-vetted plugins can reasonably handle.

Both approaches give a client markup a competent developer can actually read and extend five years from now, without needing to reverse-engineer a specific vendor's internal conventions first. That five-year horizon matters more than it sounds like it should in a scoping conversation, because most sites we build outlive at least one team reorganization, one rebrand, and often the original developer who built them.

We're not against them categorically, and we say so directly when it's true. A single-location small business with a five-page site, no meaningful growth plans, and a founder who wants to make small text edits themselves without calling anyone doesn't need a custom Next.js build. Webflow or Squarespace can be the right, honest, and genuinely cheaper answer there.

The problem isn't the tool existing. It's using it by default for a site that's clearly going to outgrow it within a year or two, because the migration cost when that happens is almost always higher than the setup savings ever were. We try to have that conversation honestly at the very first call, before a client has committed budget to the wrong tool for their actual trajectory.

We quoted a migration for a client running a five-year-old page-builder site recently, and the estimate came in close to what a full rebuild from scratch would have cost anyway, because so little of the underlying structure was reusable. That's the number worth knowing upfront, before choosing a page builder for anything meant to last.

The client's original setup cost was genuinely lower three years earlier. The total cost across the site's life, setup plus this eventual migration, ended up higher than if they'd started on a proper framework from day one. We show prospective clients this kind of real comparison now instead of just asserting page builders are worse.

We also now include a short technology section in every proposal explaining, in plain language, what we're building on and why, specifically so a client understands the tradeoff they're accepting before the project starts rather than discovering it years later when they try to make a change themselves.

Some clients love their current page-builder site, having built real muscle memory around editing it themselves, and a recommendation to move off it can land as a criticism of their own work rather than a technical suggestion. We try to separate the two explicitly: the content and design decisions they made are usually good ones, and the platform underneath is a separate question entirely.

Framed that way, most clients are relieved rather than defensive, because we're not asking them to redo their thinking, just to rebuild the same decisions on a foundation that will actually hold up as the site grows and changes over the following years.

A client's business doesn't get a vote when a page-builder company raises its monthly plan price by 40 percent overnight, changes what counts as a billable page, or gets acquired and quietly sunsets the product two years later. We've seen all three happen to sites we didn't build, and in every case the client's only real options were to keep paying a worse deal or fund an unplanned emergency migration on someone else's timeline, not their own.

That's a business continuity risk most clients never think to ask about when they're comparing an $18-a-month plan to a $6,000 custom build, because it doesn't show up anywhere in a features comparison chart. We now raise it directly in scoping conversations, with real examples of pricing changes and shutdowns from builders in the market, so the decision accounts for the whole risk, not just the sticker price at signup.

Several widely used page builders inject render-blocking scripts, duplicate heading structures, or bloated DOM trees that a content team can't fix no matter how well they write or structure their copy, because the problem lives in the platform layer underneath the content, not in the content itself. We've run technical audits where every on-page SEO fundamental was genuinely solid and the site still underperformed on Core Web Vitals purely because of how the builder assembled its own markup.

This is a harder conversation to have with a client than a simple content fix, because it means the honest answer to "why isn't this ranking better" is sometimes "the platform itself is capping how well this can perform," not anything the marketing team did or didn't do. We'd rather have that conversation clearly during a technical audit than let a client keep investing content budget against a ceiling no amount of good writing can lift.