WordPress or a custom-coded website? How to actually decide

Almost every project starts with this question, and almost every answer you get is biased. Agencies that only build WordPress will tell you WordPress. Developers who prefer writing code will tell you custom. Neither answer is about your business.

The honest version is simpler than either camp admits: this is not a technical decision, it's an editorial one. It comes down to who is going to change the words on your website, and how often.

The one question that decides it

Ask yourself: in a normal month, how many times will someone need to change the content?

• Several times a month or more — you're publishing posts, adding packages, changing prices, announcing events. You need a content management system. WordPress is a sensible default.
• A few times a year — your services are stable, your pages rarely change, and updates are occasional. A custom-coded site will serve you better and cost less to run.

That's genuinely most of the decision. Everything else is detail that follows from it.

When WordPress is the right call

WordPress earns its place when content is the point of the site:

• You publish regularly. A blog, news section, or a stream of new tour packages, properties or products.
• Non-technical people need control. Your team should be able to fix a typo at 9pm without messaging a developer.
• The site will keep growing. New pages get added month after month rather than being fixed at launch.
• You need a specific ecosystem. Some tools — certain booking, membership or e-commerce systems — have mature WordPress plugins and no realistic alternative.

The catch is that WordPress is not "free" in the sense people assume. It's free to install, but core, themes and plugins need updating, and out-of-date installs are the single most common way small business sites get compromised. That's a real ongoing commitment — either your time or someone else's.

When custom-coded is the right call

• Your content is stable. A brochure site, a portfolio, a landing page for one service — things that change a few times a year.
• Speed genuinely matters. With no database queries, no theme layer and no plugin overhead, a static site has far less to do before something appears on screen.
• You want a smaller attack surface. No admin login and no plugin stack means dramatically less to keep patched.
• The design is unusual. Bending a theme into a shape it wasn't built for often costs more than building the thing directly.

The trade-off is honest too: without a CMS, content changes go through whoever maintains the code. If that's a bottleneck for you, it's the wrong choice — no matter how fast the site is.

Three things people get wrong

"WordPress is easier"

Easier to edit, yes. Easier to own, no. You're taking on updates, backups, plugin compatibility and security. That's manageable, but it should be a decision you make deliberately rather than something you discover a year later.

"Custom means nobody else can ever touch it"

Only if it's built badly. Clean, semantic, commented HTML and CSS is readable by any competent developer. What actually locks you in is undocumented complexity — and that happens on both sides of this choice.

"WordPress is bad for SEO" / "WordPress is good for SEO"

Neither. Search engines read the HTML that arrives in the browser. A well-built WordPress site and a well-built custom site can produce near-identical markup. What moves the needle is structure, speed, metadata and internal linking — none of which the platform decides for you. An SEO plugin is a set of empty fields, not a strategy.

Cost: the part nobody separates properly

There are two different costs, and mixing them up causes most of the regret:

• Build cost — the one-off cost of getting the site made.
• Running cost — hosting, updates, backups, plugin licences, and the cost of your time or someone else's every month afterwards.

A CMS shifts cost from build to running. A custom site shifts it the other way. Which is cheaper over three years depends entirely on how often your content changes — which brings you right back to the first question.

If you can't answer "who will edit this, and how often?", you're not ready to choose a platform yet. Answer that first and the rest follows.

A short checklist

1. How many content changes per month? More than a couple → lean CMS.
2. Who makes them — you, a team member, or a developer?
3. Is there a specific plugin or tool you genuinely depend on?
4. Who will apply updates and check backups? Name an actual person.
5. Is the design standard enough for a theme, or does it need building?

Answer those five and the platform usually picks itself. If two of them point in opposite directions, that's worth a conversation rather than a guess.

---

I build both — WordPress sites when content changes often and your team needs control, and custom-coded sites when stability and speed matter more. If you're not sure which fits, tell me how often your content changes and I'll give you a straight answer, including when the answer is "you don't need me for this".

Whichever way you go, the technical groundwork matters more than the platform — see SEO services for what that involves, and website maintenance for keeping it working afterwards.