Why we build without page builders

Demo content — a placeholder post about build philosophy. No client names or figures are used.

Page builders promise speed: drag a block, publish a page, move on. For a lot of sites that trade-off is fine. For sites where performance and long-term maintainability matter, it usually isn't — and the reasons are more concrete than "hand-code is better."

What a page builder actually ships

Most visual builders ship a general-purpose runtime capable of rendering any layout a user might drag together. That flexibility has a cost: extra JavaScript, extra CSS, and DOM structure that exists to support configurations the specific page never uses.

• Every page pays the runtime tax, not just the complex ones
• Markup depth grows with builder version, not with page complexity
• Custom behavior often means fighting the builder's assumptions

What hand-coding buys back

A hand-built page ships exactly the HTML, CSS, and JS the page needs — nothing generic sitting underneath it. That typically shows up directly in Core Web Vitals, particularly LCP and CLS, because there's no wrapper runtime deciding layout at the last moment.

A minimal example

<section class="hero">
  <h1>Ship less, load faster</h1>
</section>

No builder scaffolding, no inline style tag injected by a visual editor — just the markup the page actually needs.

The real cost

Hand-coding is slower per page and requires a developer, not a marketer, to make structural changes. That's a real cost, and it's worth naming honestly rather than pretending it doesn't exist — see the MDN guide to semantic HTML for why structure-first markup pays off beyond just speed.

The trade-off is speed of initial build versus speed of the shipped site and the ceiling on how far it can scale. For most of what we build, we bet on the latter.