Pagebuilders are visual editors that drag-and-drop a website together. Elementor, Divi, WPBakery, the Wix Editor, all in this category. They are popular because they look like productivity. We don't ship them for client work because the bill they generate is paid by the client, every month, in performance, in plugin fees, and in the eventual rebuild. Hand-written code is slower to start and faster to live with.
This is not a religious position. It is an arithmetic one. Below is the math, the trade-offs we considered, and the small set of cases where we will use a visual tool.
What is a pagebuilder, exactly?
A pagebuilder is a drag-and-drop visual editor that generates a website's HTML and CSS for you. You move blocks around in a browser, the tool spits out a page. The convenience is real. The output is the problem.
Most pagebuilders ship 4 to 10 times more HTML and CSS than the page actually needs. They load multiple competing JavaScript libraries, often jQuery, often a runtime style engine, often a custom animation system on top. Even on a $300 design, you end up with a 3 megabyte first paint and a Lighthouse score in the 50s.
What does a pagebuilder actually cost over 3 years?
The up-front cost looks great. The 3-year cost does not. Here is a rough breakdown for a small business site.
- Year 0: $1,500 build fee, $300 in plugin licenses, $150 hosting. Total $1,950.
- Year 1: $300 plugin renewals, $150 hosting, $400 in dev hours fixing breakages from auto-updates. Total $850.
- Year 2: Same as Year 1, plus $1,200 to redesign sections that look dated. Total $2,050.
- Year 3: Full rebuild because the original builder shipped a breaking major version. $2,500. Total $2,500.
That is around $7,350 over 3 years for a site that is slower than it should be, and that you will eventually throw out and pay to rebuild. A lean hand-coded site avoids most of that: no plugin renewals, no builder subscription, and hosting that costs very little.
What does the difference actually look like?
Here is a typical example. Picture a 28 page Elementor site on a shared host. Its landing page ships around 3 megabytes of HTML, CSS and JavaScript on first load, and phones wait several seconds before anything useful appears. Rebuilt by hand with the same content, the same page can weigh a small fraction of that and load almost instantly.
A hand-coded version of that kind of page typically lands under 100 kilobytes, scores in the high 90s on Lighthouse mobile and shows its main content in well under a second.
Same design. Same copy. Far less code shipped to the browser, and a much faster site for every visitor on a phone.
Numbers like these are not edge cases. They are typical when a pagebuilder gets replaced with hand-written code by a team that knows what to cut.
What do you lose when you ship a pagebuilder?
Three things, in order of pain:
- Performance. Sub-second LCP is effectively impossible. Performance engineering is one of the things we ship, and pagebuilders make it un-ship-able. Slow sites convert worse, rank worse, and feel cheap.
- Control. When the design needs a tweak the builder does not support, you are stuck. The escape hatch is "custom CSS injected into a text field", which is the worst of both worlds.
- Ownership. The site is locked to the tool. If the tool is acquired, deprecated, or simply has a bad release, you inherit the chaos. We ship code you can move to any host, any team, any time.
What do you give up by going hand-coded?
Honest answer: a little speed at the start, and a slightly steeper editing experience if you wire it badly. We solve the second problem by pairing the front-end with a clean headless CMS, usually Sanity or Payload. Your team edits content through a curated admin UI. The page renders from clean code. There is no plugin to break on Tuesday.
You also give up the false comfort of "anyone on the team can rebuild the site". In practice, no one ever does. Marketing teams do not have the bandwidth to redesign pages, and when they try, the result is the visual equivalent of a ransom note. A clean code base with a content layer is what they actually want.
When do we use a visual tool?
We will use Webflow or Framer when the brief genuinely fits: small marketing sites where the client wants in-place editing more than they want sub-second LCP, prototypes that need to ship in 5 days, or microsites for campaigns with a 6-month lifespan. The line we hold is the output. If the tool ships HTML and CSS we would not write by hand, we do not use it. If we cannot defend the output to the client and to ourselves, we do not use it.
The short version
Pagebuilders are a productivity tool for the studio that builds the site, not the business that runs it. We are not optimizing for our delivery time. We are optimizing for your operating cost over 3 years. That math points one direction. To talk through what your build looks like specifically, head to contact.