Page builders get an unfair kicking from developers. They are fast, they let a non-technical person change a headline without raising a ticket, and for a lot of businesses that is exactly right.
So this is not an argument that they are bad. It is an argument about where the line sits, because picking wrong is expensive in a way that only shows up later.
What a builder is genuinely good at
If your site is mostly marketing pages, changes often, and is edited by people who do not write code, a builder earns its keep. The alternative — a developer in the loop for every copy change — is slower and costs more.
Builders are also fine when the site is small enough that performance overhead does not matter. A five-page brochure loading in 2.5 seconds instead of 0.9 is not what is holding that business back.
Where it starts to hurt
Weight. A builder ships a generic engine that can render anything, so it carries code for every layout you did not use. A typical builder page loads several hundred kilobytes of CSS and JavaScript before your content. Hand-built, the same page is often under 100 KB total.
That matters most on a phone on a poor connection — which, for most businesses, is the majority of traffic.
Lock-in. The layout is stored in the builder's own format. Migrating means rebuilding, not exporting. Two years in, that is a real cost that never appears in the original quote.
The plugin stack. Builders lean on plugins, and each one is another update to install, another thing that can break on a version bump, and another maintainer who might abandon it.
Structural control. Semantic markup, structured data, heading order and accessible components are all possible in a builder — but you are working against defaults rather than with them.
The honest test
Ask what the site has to do in three years, and who edits it:
- Marketing pages, edited weekly by non-developers, no complex logic → builder, and do not feel bad about it.
- A product, a portal, listings, a dashboard, anything with users or records → hand-built. Builders model pages, not systems.
- Somewhere in between → hand-built templates with a small admin panel for the parts that genuinely change.
That third option is what most of our clients end up with, and it is the least discussed. You do not have to choose between "developer for every change" and "a builder for everything". You can hand-build the shell and expose exactly the fields that need editing.
What we do and why
We build in plain, dependency-light code and hand over an admin panel for the content that changes. Not because builders are beneath us — because the sites we are asked for usually have a system behind them, and that is where builders stop being the right tool.
The practical upshot: a page that loads fast, markup we control, no monthly licence, and no migration project the day you outgrow the platform.
A quick way to check yours
Open your site on a phone, on mobile data, and count. Then open the browser's network tab on desktop and look at the total transferred. Over about 1.5 MB for a marketing page and you are paying a weight tax for flexibility you may not be using.
If that is where you are, the fix is not always a rebuild. Often it is removing three plugins and half the fonts.
