Here is the whole decision in one question: after launch, will someone who is not a developer need to change the words on this site? If yes, you want a CMS, and for most business sites that means WordPress. If no, custom code is lighter, faster and cheaper to keep alive. Everything else in this argument is detail.
What makes the choice feel harder than it is: WordPress carries a reputation earned by the worst examples of it, twenty plugins deep and loading four megabytes of JavaScript to show a phone number. That is a decision about how a site was built, not about what WordPress is. This site runs WordPress with a hand-coded theme and no page builder, and it behaves like a static site because nothing in the stack is doing work it was not asked to do.
The short answer
| Your situation | Pick |
|---|---|
| Marketing site, someone in the team edits copy | WordPress |
| Blog or any growing library of content | WordPress |
| Five pages that change once a year | Custom code |
| Landing page for one campaign | Custom code |
| Content plus an app-like product surface | Custom code, or WordPress for the marketing half only |
| You have in-house developers and no content team | Custom code |
| You have a content team and no developers | WordPress, without question |
What a CMS actually buys you
Somebody else can change the words
This is the entire value proposition and it is worth more than it sounds. On a custom-coded site, fixing a typo in the hero means a developer, a commit and a deploy. Do that four times a month for two years and the “cheaper” option has quietly cost more than the CMS would have, in both money and in the delay between noticing something and fixing it.
Everything routine is already solved
Contact forms, redirects, SEO metadata, sitemaps, image resizing, scheduled publishing, user roles. None of these are hard problems, and all of them are hours you do not spend. Yoast alone replaces a meaningful amount of custom work on metadata and sitemaps that nobody enjoys writing twice.
You are not the only person who can maintain it
WordPress powers a large share of the web, so if you and I stop working together you can hand the site to almost anyone. A bespoke stack built around one developer’s preferences is a smaller hiring pool and a real risk you carry quietly.
What it costs you
The update treadmill
Core, plugins and PHP all move. Something needs updating most months, and skipping updates is how sites get compromised. It is maybe fifteen minutes of attention a month on a lean install, but it is not zero and it never ends.
A larger surface to attack
Popularity means automated attacks. A WordPress site with four plugins from reputable authors, kept current, is not a risk worth losing sleep over. A site with twenty-two plugins, three of them abandoned since 2023, is a different proposition entirely.
A performance ceiling you can raise but not remove
WordPress builds pages on request, so there is always a server round trip that a static file does not need. Good caching narrows this to the point of irrelevance for a business site. It is real, though, and if you are chasing the last hundred milliseconds, static wins.
The plugin trap
This is where WordPress sites actually go wrong. Every plugin is a dependency you did not write, loading its own CSS and JavaScript on every page whether the page uses it or not. Page builders are the worst offenders: they solve the editing problem by shipping a rendering engine to every visitor. Four plugins is a healthy install. Twenty is a maintenance liability wearing a website costume.
What custom code buys you
Exactly what you designed, and nothing else. No theme conventions to fight, no plugin deciding your markup, a page weight you control to the kilobyte. Hosting can be a CDN rather than a server, which is fast, cheap and has almost nothing to break. For a portfolio, a documentation site, a campaign page or anything whose content changes rarely, it is the better engineering decision by a distance.
The cost lands entirely on content. Every change routes through someone who can use git. That is fine when the person who owns the content is also the person who can deploy, and it becomes a bottleneck the moment those are two different people with two different calendars.
The option most of this argument ignores
WordPress with a hand-coded theme and no page builder is not a compromise between the two, it is most of both. You write the templates yourself, so the markup, the CSS and the payload are yours. Editors still get a familiar admin to change copy and add posts. You skip the page builder entirely, which is what causes the bloat people actually complain about.
That is how this site is built and how I build for clients: a custom theme, a handful of plugins doing real jobs, and content fields wired so the client edits copy without touching layout. It is also why the WordPress versus custom code framing is a little false. The real question is whether you accept a page builder, and the answer to that one is no.
If your comparison is between two hosted CMS platforms rather than between a CMS and code, that is a different trade-off and I covered it in Webflow versus WordPress for business websites.
How to decide in five minutes
Answer these honestly:
- Who edits content after launch, and can they use git? If the answer is a marketer, a founder or an assistant, you need a CMS.
- How often does content change? Weekly means CMS. Once a year means code.
- Is there a blog, or will there be? A growing content library on a coded site means either a build step and a static generator or a lot of copy and paste.
- Who maintains this in two years? If you cannot name a person or a type of person, pick the platform with the larger hiring pool.
- Does it need logins, dashboards or real application logic? That is a product, not a website, and it belongs in code regardless of what the marketing pages run on.
Cost tracks these answers more than it tracks the technology, which I broke down in what a custom website costs, and the timeline barely moves between the two, as covered in how long a website takes to build.
Frequently asked questions
Is WordPress slow?
WordPress is not slow. Twenty plugins and a page builder are slow. A custom theme with deferred scripts, modern image formats and sensible caching scores in the nineties on mobile Lighthouse, which is where a business site should be. The platform sets a ceiling most sites never come close to touching.
Is a custom-coded site more secure?
It has a smaller attack surface, mostly because there is no login and no database. That is a genuine advantage. A maintained WordPress install with few plugins, current versions and a decent host is not the liability it is made out to be, and an unmaintained anything is a problem eventually.
Can I start with custom code and move to WordPress later?
Yes, and it is a common sequence: launch a fast marketing site, add the CMS once someone actually needs to edit weekly. Keep your URL structure sane from day one so the migration is a template job rather than a redirect nightmare. The redesign checklist covers the URL side of that move.
What about static site generators?
A good middle path for technical teams. You get static output with content in files, and increasingly with a small headless CMS on top. The catch is the same one custom code has: your editors need to be comfortable with the workflow, and most non-technical clients are not, whatever the demo suggests.
Does Google care which one I use?
No. It cares about speed, structure, mobile behaviour and content quality, all of which you can get right or wrong on either. Platform choice is not a ranking factor. What you build with it shows up in the metrics that are.
If you are weighing this up
Most of the time the honest answer comes out of two or three questions about who edits the site and how often, not out of a technology preference. If you want a straight opinion on which side your project falls, send me the outline. You can see the kind of builds I take on in my case studies.
Planning a website or product design project?