The question usually arrives in the middle of a quote conversation, and it is almost always phrased as a preference. Should we build this with a page builder, or should you write a custom theme for us? People ask it the way they would ask about a paint color. It is not that kind of question. It is a question about who can change your website in three years, what happens when a plugin you didn’t choose stops being maintained, and how much a small edit will cost you in the fourth year of owning it.
I have been building WordPress sites since 2006, and I have inherited sites built both ways from developers who are no longer reachable. Both approaches produce sites that work. Both produce sites that quietly become expensive. The difference is in which bill arrives, and when.
What each one actually is
A page builder is a visual editing layer that sits on top of WordPress. You lay out a page by dragging sections and widgets, adjusting padding, typing in a sidebar, and seeing the result immediately. The layout you build gets saved as structured data that the builder reads back and renders on every page load.
A custom theme is code written specifically for your site. Templates define a page’s structure, a stylesheet defines its appearance, and the editing experience your team sees is whatever the developer chooses to expose, usually a set of defined fields in the WordPress editor.
That difference, visual layer versus written template, is the root of every trade-off below.
Where a page builder earns its keep
A builder is the right answer more often than purists admit, for three practical reasons.
Your team can actually change things. This is the whole argument, and it is a strong one. If the person who needs to add a staff bio, swap a seasonal banner, or build a landing page for a grant deadline is a program director rather than a developer, a builder means they do it on Tuesday afternoon instead of filing a ticket and waiting. I have watched organizations go from four site edits a year to forty once the editing stopped requiring me.
New pages do not require a new budget. In a custom theme, an unanticipated page layout is a development task. In a builder, it is an afternoon. For a small business adding a service line or a nonprofit running a different campaign every spring, that flexibility is worth real money.
Where a custom theme earns its keep
The case for written templates is not aesthetic. It is structural.
Consistency is enforced rather than remembered. When a layout lives in a template, every page using that template is identical by definition. When it lives in a builder, consistency depends on whoever edited last. This is the single most common thing I find on inherited builder sites: fourteen pages that were identical at launch and now have nine different heading sizes, because small decisions accumulated over two years with nobody arbitrating them.
Repeated content gets cheaper, not more expensive. If your site has sixty staff profiles, four hundred products, or a catalog that changes weekly, store that content as data and render it with one template. Building sixty pages by hand in a builder means sixty places to update when the layout changes.
Less sits between your content and the browser. A builder renders through an interpretation layer, and it ships CSS and JavaScript to support features a given page may not use. A tuned custom build sends less. On a content site, the difference is often modest. On a large store or a site serving readers on slow connections, it is not.
The structure of the page is yours to control precisely. Heading order, landmark regions, and the reading sequence a screen reader follows are all decided in the template rather than inferred from how a layout was assembled. You can get this right in a builder, and we do, but you have to go looking for it. In a template, it is the default.
Four questions that settle it
Instead of debating the technology, answer these.
Who edits this site, and how often? If the answer is a non-technical person, weekly, a lean builder. If the answer is a developer, rarely, the case for templates strengthens considerably.
How much of your content is repeated structure? Count the page types where you would have more than fifteen near-identical pages. A lot of them point to templates. Twelve bespoke pages point to a builder.
What does one hour of downtime or one broken page cost? If a broken checkout costs you real revenue within an hour, you want fewer moving parts and a tighter staging and testing routine, no matter how you build.
Who maintains this in year three? People skip this question, and it decides the total bill. A builder site can be maintained by a large pool of people. A custom theme can only be maintained by someone willing to read another developer’s code, a smaller, more expensive pool. Neither is wrong. Only one of them is a surprise.
Mistakes I keep watching people make
Buying a builder and then not using it. An organization pays for the flexible option, never gets twenty minutes of training, and goes right back to emailing change requests. They are now paying for a capability they do not have. The fix is a single hour of training on their own pages, not a different platform.
Stacking three builders on one site. A theme with its own builder, a second builder from a previous developer, and a handful of widget add-on plugins, all loading at once. Each one has to load on every page. I find this constantly on sites that have changed hands twice.
Building a catalog by hand. Sixty pages assembled individually in a builder isn’t a website; it’s sixty websites. The moment the layout needs a change, the cost of that decision becomes obvious all at once.
Choose the stack before defining the content. Decide what the site has to hold first. The right build method is usually obvious ten minutes after that conversation, and arguing about it beforehand is arguing in the dark.
What we usually land on
Most of the sites Modus Medium builds are a deliberate mix. The marketing pages, the ones your team edits, reorganizes, and seasonally rewrites, are built so you can update them without calling anyone. The repeating content — the profiles, products, and case studies — runs through templates so one change propagates everywhere and the hundredth entry costs the same as the second. Then we hand it over with documentation and a session showing your team how to work in it, because a site your team cannot edit gets stale in month four.
Make the decision out loud before anyone writes code, with the trade-offs named in plain language. You should know in advance which edits will be easy, which ones will require us, and roughly what each costs.
Your next step
Before you ask anyone to quote a build, write down two lists. First, every page type your site needs. Second, next to each one, the number of pages that type will eventually hold and the name of the person who will edit it. That one page of notes will tell you more about how your site should be built than any comparison article, this one included.
Bring that page to a consultation, and we will walk through it together, name which parts your team should be able to edit and which should be templated, and put real numbers against each. Start on the web design and development services page, or go straight to contact and send the two lists along with your current site address.