For about three years, we built most of our client sites with page builders. Elementor, then Bricks, then occasionally Breakdance. The pitch made sense: faster builds, lower prices, easier handoffs. By 2024 we’d built more than 80 sites this way, and the work was profitable.
Then we stopped. This is why.
The first sign was the support tickets
About 18 months in, we noticed the same pattern in our support inbox. A site we’d launched would run cleanly for 6–9 months, and then we’d get a ticket. Something visual was off, or a layout had broken on mobile, or a section had stopped looking right after the latest builder update.
The fixes were never hard. They were also never satisfying. We were spending billable hours patching the work of a tool we didn’t control, and our clients were paying for the privilege of being on the receiving end of that update cycle.
We measured it. Across 30 of our active page-builder sites, we were spending an average of 47 minutes a quarter, per site, on bugs introduced by the builder. Multiply across the portfolio and it was a meaningful chunk of senior time vanishing into work that didn’t compound.
The performance cost was real and unfixable
We knew page builders were heavier. The Lighthouse score on a clean Elementor build was usually 75–85; we could push it to the low 90s with effort. A custom-coded equivalent landed at 95+ without trying.
What changed our minds was the resilience. The page-builder site at 92 would drift back to 85 over a year as content was added, plugins activated, and updates compounded. The custom-coded site at 96 mostly stayed at 96. Performance optimisation in a page-builder site is a Sisyphean task. You spend a day getting the score up, and then the next plugin update or the next content edit pulls it down.
For most of our clients this didn’t matter much. For the ones investing in SEO and paid traffic, it mattered a lot. The page-builder sites were quietly leaking conversion at the edges, and we couldn’t fix it without rebuilding.
The lock-in problem
Five years from now, the dominant page builder won’t be Elementor. It might be Bricks. It might be something we haven’t heard of. The builder you bet on today might be acquired, deprecated, or fall out of favour to the point where finding developers who know it well becomes hard.
We watched this happen with Cornerstone, with Visual Composer, with WPBakery. Sites that had been built with these tools became progressively harder to maintain as the developer market moved on. Our clients didn’t sign up for that risk. They didn’t even understand the risk existed.
“You will never regret writing your code in HTML, CSS, and PHP,” one of our senior developers said in a planning meeting where we were arguing about this. He was right. The languages don’t go anywhere. The tools sometimes do.
The handoff problem
Eventually, every client engagement ends. Sometimes our clients hire an in-house developer. Sometimes they switch agencies. Sometimes they sell the business and the new owners want to bring development in-house.
Our handoff document for a custom-coded site is six pages. The new developer reads it, browses the code, and is productive within a day.
Our handoff document for a page-builder site was twelve pages and ended with “but really, it’s easier if we just keep maintaining it.” This wasn’t a sales pitch. It was a real observation. Page-builder sites are coupled to the specific builder, the specific plugin set, and the specific patterns we’d developed for working around them. New developers spent days getting oriented. Some refused the work entirely.
That’s an uncomfortable thing to be selling. We’d built our business on the idea that clients should own their work and be free to leave whenever. Page builders quietly undermined that.
What we do now
We build custom-coded WordPress themes. The starting price is higher: $6,500 for a build we previously would have done for $3,500 with a page builder. The clients who can’t afford that go to other agencies, and that’s fine.
The clients who can pay for it get a site that loads twice as fast, holds its performance over time, hands off cleanly to any developer in five years, and doesn’t leak our team’s time into bug-fixing the work of a tool we don’t control.
We still use page builders for clients with the right profile — small budget, simple site, willingness to live with the trade-offs. But we’re honest about what those trade-offs are. Our comparison article walks through the decision, and the agencies that don’t have this conversation with clients are doing them a disservice.
The last 18 months, since we made the change, our retention has gone up, our support burden has gone down, and our team is doing work they’re more proud of. The financial math worked out fine — we have fewer projects, but each is more substantial. Our smaller-agency philosophy made this transition easier than it might have been at scale.
If you’re choosing between a page-builder build and a custom one, the question isn’t “which is better.” It’s “which trade-offs am I willing to live with?” Both are legitimate answers. Just make sure you’re choosing.
