There's a moment in most small-business website projects where someone says, “let's just use a builder.” The thinking is reasonable: builders look fast, they look cheap, and they let one person ship something visible by the end of the week. What the builders don't tell you is that the cost shows up two years from now, when the plugins start to drift and nobody can find which one is rendering the contact form.
We've inherited a lot of builder sites. Almost without exception, the pattern is the same: a respectable launch, six months of decent traffic, and then a slow slide. Pages get heavier. Plugins update on their own schedules and occasionally don't. The page-builder's CSS fights the theme's CSS, and the loser is the visitor on a phone in a parking lot.
The default failure mode of builders
It's not that page builders are bad. It's that the convenience that makes them feel cheap also makes them structurally expensive over time. Four patterns we see again and again:
- Plugin sprawl. Each new feature is an install. After a year, the site has 27 plugins and no one knows which six are actually needed. Each one is a third-party security surface and a third-party update schedule.
- CSS specificity wars. The theme's styles, the builder's styles, and your custom overrides take turns winning at different breakpoints. The result looks like a different site on every device.
- Performance debt. Builders ship CSS and JavaScript for blocks you didn't use. A homepage that needs 40 KB of code arrives at the browser with 1.8 MB.
- Update churn. Themes, builders, plugins, and the underlying CMS update on different cycles. Eventually one of them breaks the others, and you find out in production.
None of this is hypothetical. Every one of these failures shows up in clients we inherit from other shops. The fixes are rarely fast and rarely cheap.
What custom-coded actually means
When we say a Catalyst site is custom-coded, we mean it literally. HTML, CSS, and a small amount of JavaScript — written for your site, by hand, in editor windows that look a lot like the photo at the top of this post. We use a small set of opinionated patterns we've refined across builds. We do not ship blocks of code your site never executes.
The practical effect: a typical Catalyst homepage is somewhere between 200 KB and 500 KB on first load, including images. Lighthouse scores sit in the high 90s on mobile. Time-to-interactive is under a second on a mid-range phone. None of that is magic. It's just what happens when you don't ship code you don't use.
The simplest stack that does the job is almost always the one that ages best.
A real comparison
One recent client came to us with a builder-based site we won't name. Page weight: 6.2 MB on the homepage. Largest Contentful Paint: 4.8 seconds on a throttled 4G connection. The site had 23 plugins, three of which were actively used and one of which was eight years out of date.
We rebuilt it. Same content. Same brand. Same forms. Static HTML, a single stylesheet, one short script for the mobile menu. Page weight after the rebuild: 280 KB. LCP: 0.9 seconds. The client kept their existing copy and most of their photography. Nothing about the rebuild was clever — it was just less.
When a builder is the right call
This is not a one-sided argument. Builders earn their place in three situations:
- Throwaway sites. A landing page for an event next month? Use a builder. It will be gone before any of the long-tail problems matter.
- Internal-only tools. Performance and SEO don't matter when only five people see it.
- Owners who will truly edit it themselves. If the founder is going to be in the page editor every other week, the builder's learning curve is part of the value. We've watched a lot of owners say this and never actually do it — ask honestly.
The middle path we like
The lazy critique of custom-coded sites is that the owner can never update them. That hasn't been true for years. Every Catalyst build ships with a small content-editing surface for the parts that actually change — copy, photos, blog posts, GBP-style content. Layouts and components stay in code, where they belong. Content stays in a place the owner can reach.
The result is a site that loads fast, looks consistent across devices, doesn't require monthly plugin updates, and still lets you swap out a hero photo without a developer in the loop.
It's not nostalgia
We don't hand-code sites because we're attached to a particular era of the web. We hand-code them because the trade-offs keep favoring it: less code, fewer moving parts, faster pages, calmer maintenance, better SEO. Builders will get better. Until they do, the simplest version of the work is also the durable one.
