A developer comparing two approaches on a large monitor

WordPress or a custom build: how to actually choose

Development · 9 min read · by the WebrixLab team

Developers have opinions about this and most of them are about the developer, not about you. The honest answer is that the right choice is decided by one question almost nobody asks first: who is going to change this site six months from now, and how often?

We build both. Here is how we actually decide.

What WordPress is genuinely good at

WordPress runs a large share of the web for real reasons, not just inertia.

  • Non-technical people can edit it. This is the whole argument, and it is a strong one. If your marketing person needs to publish a page on Tuesday without filing a ticket, WordPress does that.
  • The ecosystem is enormous. Booking, e-commerce, memberships, multilingual - the plugin probably exists and has been tested by thousands of sites.
  • It is not a lock-in. Any WordPress developer can pick up a standard build. You are not tied to whoever made it.
  • It is fast to launch. Weeks, not months, for a typical business site.

What it costs you

Also real, and usually understated in the sales conversation.

Maintenance is permanent. Core, themes and plugins update constantly, and updates occasionally break things. Someone has to own that. Sites that go unmaintained for a year are the ones that get compromised - and it is almost always an outdated plugin, not a clever attack.

Performance takes discipline. A default WordPress build with a page builder and fifteen plugins is slow. It can be made fast, but that takes deliberate work, and most builds do not get it.

Plugins accumulate. Each one is code you did not write, updated by someone you do not know. Five is fine. Thirty-five is a liability.

The right answer is usually decided by who edits the site, not by what the developer prefers
The right answer is usually decided by who edits the site, not by what the developer prefers.

When a custom build is the right call

Custom does not mean better. It means you are paying for control, and it is worth it when you need it.

  1. Your core function has no plugin. If the thing your business does is the thing the site must do, and no off-the-shelf tool matches it, stop trying to force one.
  2. Performance is a competitive requirement. High-traffic commerce, or an audience on poor connections, where every hundred milliseconds shows up in revenue.
  3. You have a real security or compliance burden. Fewer moving parts, fewer third-party dependencies, a smaller surface to defend.
  4. The site is really an application. Dashboards, calculators, portals, anything with logged-in users and state.
Choosing custom because WordPress feels unserious is the most expensive reason to choose custom.

The three-year cost, which is the one that matters

Comparing build quotes is the wrong comparison. Compare three years.

WordPress: lower upfront, then hosting, premium plugin licences, maintenance, and periodic work when something breaks. Content changes are close to free because your team makes them.

Custom: higher upfront, lower ongoing maintenance, but every content structure change is a developer task. If you publish frequently and cannot edit it yourself, that adds up faster than people expect.

The break-even usually turns on publishing frequency. Teams that publish weekly are almost always better served by a CMS. Teams that change the site twice a year can afford custom.

The middle ground most people should consider

You do not have to pick a corner. A custom-built theme on WordPress gives you clean, purpose-written code and the editing experience your team needs. Or a headless setup, where WordPress handles content and a separate front end handles rendering - more moving parts, but genuinely fast.

Most of what we build sits here: WordPress underneath because a human has to edit it, with the theme written properly instead of assembled from a page builder.

Questions that settle it

  1. Who edits the site, and how often? Weekly by a non-developer means CMS. Quarterly by us means custom is viable.
  2. Does the core function exist as a mature plugin? If yes, use it. If no, do not bend one into shape.
  3. Do you have a maintenance budget? If not, WordPress will become a security problem. Be honest here.
  4. Is speed commercially critical or just desirable? Both are valid answers. They lead to different builds.
  5. What happens if this agency disappears? Whichever you choose, the answer should be "someone else picks it up".

The page builder question

Most WordPress sites sold today are built with a page builder - Elementor, Divi, WPBakery and similar. It is worth understanding what you are getting.

What you gain: your team can restructure a page without a developer, and the agency can build faster, which is part of why quotes come in lower.

What you pay: weight. Page builders ship generalised markup and CSS for every layout they might need, not the one you are using. On a typical build that is several hundred kilobytes of code doing nothing. They also create lock-in that people underestimate - move away from the builder and your pages become unusable shortcodes.

Our position, for what it is worth: page builders are a reasonable trade for a small brochure site where publishing speed matters more than milliseconds. For anything where search and speed are commercially important, a properly written custom theme with editable blocks gives you the same editing experience without the payload.

Security, honestly

WordPress gets described as insecure. That is mostly wrong, and the detail matters.

WordPress core is well maintained and rarely the entry point. Almost every compromise we have cleaned up came in through an outdated plugin, a nulled premium theme, or a weak administrator password. All three are choices, not properties of the platform.

A custom build has a smaller attack surface simply because there is less third-party code. But it is not automatically safe - custom code with a sloppy file upload or an unescaped query is worse than a well-maintained WordPress site, because nobody else is auditing it.

Non-negotiables either way

  • Automatic updates for security releases, with a staging site to catch breakage
  • Two-factor authentication on every administrator account
  • Off-server backups you have actually restored from once, as a test
  • No nulled or pirated plugins and themes, ever - these are the single most common infection route we see
  • Administrator accounts removed when people leave

Migration: what it costs to change your mind

People choose based on the build, then discover the exit price later.

WordPress to custom: the content is portable through the API or a database export. The work is in rebuilding templates and preserving URLs. Expect a meaningful project, not a weekend.

Custom to WordPress: usually harder, because custom content models rarely map cleanly onto posts and fields. Budget for a migration script and a content audit.

Between page builders: the worst of the three. Content built as builder shortcodes often has to be rebuilt page by page. This is the lock-in people mean when they warn about builders.

Ask what leaving costs before you ask what building costs. It tells you more about the platform than the feature list does.

A decision table

  1. Brochure site, team publishes monthly, tight budget - WordPress with a light theme. Do not overthink it.
  2. Content-led site, publishes weekly, search matters - WordPress with a custom theme. This covers most of what we build.
  3. E-commerce under a few hundred products - WooCommerce or a hosted platform. Custom is rarely justified.
  4. Booking, membership, calculators, logged-in users - custom, or a hybrid with a custom application alongside the CMS.
  5. Very high traffic where speed is revenue - custom or headless, with the hosting budget to match.

The question underneath the question

When someone asks us this, what they usually mean is "will I be stuck?" That is the right worry, and the platform is only half the answer.

You are stuck when the accounts are in the agency's name, when the code lives in a repository you cannot access, when the hosting is bundled so leaving means rebuilding, and when nobody has written down how anything works. Those things can happen on either platform, and avoiding them is a contractual matter rather than a technical one.

Ask who owns what, get it in writing, and the platform question becomes much less frightening.

What we recommend, most of the time

For most businesses under twenty pages with a team that wants to publish: a custom theme on WordPress. It is the option with the fewest regrets - you get the editing experience, without the bloat that gives WordPress its reputation.

We do build fully custom when the brief warrants it, and we will tell you when it does not. Read more about our WordPress work or how we handle custom builds. Either way, the code, the hosting and the accounts stay in your name.

Not sure which you need?

Tell us who will edit the site and how often. That usually decides it.