I’ve argued before that WordPress isn’t the problem, the setup is. This is the follow-up, because the question people ask next is still the wrong one.
“Should we build in WordPress or go custom?” gets treated as a technical decision. It isn’t. Both are capable of excellent work. Both are frequently disastrous. The platform is downstream of two questions that almost nobody asks before choosing.
Question one: who edits this, and how often?
Not “will we need to update it”. Everyone says yes to that and then doesn’t.
Be specific. Who, by name, is logging in? What are they changing? How often, honestly, not aspirationally?
“Nobody, really.” A five-page site describing services that haven’t changed in four years. A CMS here is overhead you’re paying for in complexity, hosting cost, and security exposure. A static build is faster, cheaper to run, and has almost no attack surface, because there’s no database and nothing to log into. When something needs changing twice a year, you email your developer.
“Someone in the office, most weeks.” New staff, events, listings, a blog that gets written. You need a real CMS, set up so a non-technical person isn’t nervous using it. This is where WordPress with properly built custom fields is genuinely hard to beat, and where I put most small business work.
“Our marketing person, constantly, and they want to build new page layouts.” Different build again, and the one people assume means reaching for a page builder. It does not have to. A flexible content layout in ACF Pro gives you the same thing: a set of prebuilt sections the marketing person assembles into new pages in any order, without touching code and without the loading cost or the lock-in. The sections are built once, properly, and everything stays on brand because there is no way to freestyle a layout into something that does not match the rest of the site.
It takes longer to set up than installing a builder. What you get back is a site that stays fast, stays maintainable by someone other than the original developer, and still lets the marketing team build pages on their own.
Most bad platform decisions come from answering this aspirationally. People picture the version of themselves publishing weekly, buy tooling for that person, and then never log in. Eighteen months later they’re paying for a CMS nobody opens and a plugin stack nobody updates.
Question two: who maintains it in year three?
This is the question that actually decides it, and it’s almost never discussed during a build.
Every website is a standing commitment. Someone has to apply updates, notice when something breaks, and fix it. The platform determines how much of that work exists and who’s capable of doing it.
WordPress needs regular attention. Core, plugins, and themes update on independent schedules and occasionally break each other. It’s manageable, and I maintain plenty of WordPress sites happily, but it isn’t zero. If nobody owns that job, you’ve built a problem with a delayed fuse. That’s the case I make in why your website needs ongoing maintenance.
A static site needs almost nothing. No database, no plugin ecosystem, nothing to patch. The trade is that content changes route through a developer, which is fine at low frequency and painful at high.
A bespoke application carries the highest ongoing cost, because the only people who can maintain it are people who understand it. Fine when it’s earning its keep. A trap when someone built custom for what was really a brochure site.
The honest test: if the person who built this disappeared tomorrow, could someone else pick it up? Cheap builds fail this badly and often. Undocumented, built in tooling nobody else uses, structured so any change means an afternoon of reverse-engineering before a line gets written.
What actually goes wrong
It’s rarely the platform. It’s the mismatch between platform and reality.
A page builder site that needed to be fast. Elementor and its relatives are productive to build in and heavy to load. On a marketing site competing in search, that’s a measurable cost nobody quantified at decision time.
A static site that needed a CMS. The business grew, started running events, and now every small change is a developer ticket with a two-day turnaround. What was elegant became a bottleneck.
A custom application for a brochure site. Someone got to build something interesting on your budget. Three years on there’s no documentation and they’ve moved to Melbourne.
WordPress carrying forty plugins. Each solved one small problem on the day it was installed. Collectively they’re a maintenance burden, a security surface, and a mystery, because nobody remembers what half of them do or whether anything still depends on them.
A rebuild that lost the rankings. Not a platform failure, but it happens during platform changes: new URLs, no redirects, and traffic that took four years to build evaporates in a fortnight.
How I’d actually decide
Write down, in plain words:
- Who logs in, what they change, how often
- Who’s responsible for updates and breakage after launch, by name
- What the site needs to do that’s genuinely unusual
- What happens if the original developer isn’t available
- What your content changes look like in year two, not month one
Take that to whoever you’re hiring. If they can map those answers onto a recommendation and explain what you’re giving up in each direction, they’re thinking about your situation. If they lead with the platform before hearing any of it, they’re telling you what they enjoy building.
The platform matters far less than whether it was chosen for reasons that match how you’ll actually use the thing. I’ve worked on fast, maintainable WordPress sites and on static builds nobody could touch. In every case the tool was downstream of the thinking, and the thinking is what you’re really paying for.