Developers answer this question badly. Ask one whether you should use Elementor and you get a lecture about bloat, as if every brochure site deserved a bespoke build. Ask a builder-first agency and you get told custom themes are a waste of money, as if no client ever asked for something the builder cannot do.
Both are selling. Here is the version we give agencies that ask us, including the parts that argue against hiring us.
Where builders genuinely win
For a five-page brochure site where the client wants to edit their own text and swap their own photos, a page builder is the correct answer and a custom theme is an indulgence. The client gets to change things without emailing anyone, your margin is protected, and nothing about the project needs a developer at all.
They also win on speed in a specific case: when the design is still being argued about. Dragging a section is faster than rebuilding a template, and if the client is going to change their mind four times, you want the cheap-to-change tool.
Anyone who tells you otherwise has never had to deliver a site in nine days.
The line, stated plainly
The useful question is not "how many pages?" but "does this site have to think?"
- Content that is only shown and styled — a builder handles it.
- Content with relationships, filters, calculations or rules — a builder starts fighting you.
A directory where listings filter by three criteria and relate to categories and regions. A quote form that calculates from a price table. A members area where what you see depends on who you are. Those are the point where builder projects turn into six plugins stacked on each other, each adding a settings page and a nag banner.
What a builder costs you later
The cost is rarely visible at launch. It arrives in year two.
- Lock-in. Content lives inside builder shortcodes. Changing builders later means rebuilding every page by hand.
- Plugin debt. Each missing feature becomes another plugin. Forty plugins is forty update cycles and forty chances of a conflict.
- Weight. Builders load CSS and JavaScript for components the page does not use. Fixable, but you are fixing something a custom theme never had.
- Fragility. A builder update changing how a section renders will, eventually, break a page on a Friday.
None of this matters for a brochure site the client replaces in three years. All of it matters for a site still earning in year five.
A question worth asking the client
"In two years, is this site something you will replace, or something you will have grown to depend on?" Their answer decides this more reliably than any technical argument.
The hybrid nobody talks about
Most of our WordPress work is not either option. It is a custom theme that gives editors a small set of purpose-built blocks, plus one custom plugin for the thing that actually needs logic.
The editor still edits without calling anyone — the reason builders got popular in the first place — but the blocks are the ones this client needs, they cannot be arranged into something off-brand, and the site is not carrying a page-building engine it only uses to render three layouts.
How we decide, in practice
Three questions, and the first disqualifying answer settles it.
- Does any part of the site calculate, filter or restrict? If yes, custom — at least for that part.
- Will the client edit structure, or only text and images? Only text and images means a theme with fixed blocks is safer; they cannot break the layout.
- Is anyone maintaining this in three years? If nobody is, do not build something that assumes somebody will.
And the honest closer: if the answer comes out "builder", you do not need us for that project. We would rather tell you that and get the call when the next one has a filter in it.
A two-person development studio. Custom WordPress, web applications and Android apps.
