Every platform carries an ongoing maintenance cost that is a property of the platform, not of your usage. A site that changes twice a year pays the same overhead as one that changes twice a day. That, not preference, is what decides between WordPress and a custom build.
I build on WordPress most weeks of the year, so this is not that article. WordPress is the right answer for the large majority of business sites, and I will keep saying so on calls where a custom build would earn me more.
But there is a specific shape of project where reaching for it is a mistake, and I only worked out how to describe it properly after building the alternative. The question is not “is WordPress good?” It is “does the maintenance surface match how often this thing actually changes?”
You pay the platform’s overhead whether you use it or not
Every platform you run has an ongoing cost that has nothing to do with what it does. Updates, patches, dependency churn, the occasional afternoon when something breaks because a plugin author changed their mind.
You pay that cost whether or not you use the flexibility it buys. A site that publishes twice a year pays exactly the same maintenance overhead as one publishing twice a day, because the overhead is a property of the platform, not of your usage.
So the real question is whether you are buying capability you actually spend. When you are, WordPress is superb value. When you are not, you have signed up for a permanent bill in exchange for options you will never exercise.
The decision, in one table
| If this is true of your site | Lean WordPress | Lean custom |
|---|---|---|
| Content changes | Weekly or daily | A few times a year |
| Who edits it | Several people, varying skill | One or two, trained once |
| Functionality needed | Common, an ecosystem exists | Narrow and specific |
| Growth expected | New sections, new types, often | Shape is settled |
| Integrations | Many, off the shelf | Few, and bespoke anyway |
| Tolerance for maintenance | Budgeted and accepted | Wants it near zero |
| Team | Will hire generalists later | Has, or retains, an engineer |
Most businesses land clearly on the left. If you are in any doubt, you are on the left, and that is the honest answer rather than the interesting one.
The project that sits on the right
An education consultancy came to me having already tried the cheaper route and come back. What they needed looked, at a glance, like a standard content site.
It was not, and the tell was in the change rate. The actual site content amounted to six documents: home, about, services, destinations, stories, contact. Those change a few times a year. Not weekly. A few times a year.
Against that, they genuinely needed to edit. Not just the pages, but a blog, enquiries arriving from the site, a team directory, media, and site settings. So “just make it static” was not the answer either. A static site generator solves the six documents beautifully and gives you nothing for the other five things.
That is the gap the decision usually falls into. The content is nearly static, so a CMS is overkill. But somebody still has to edit it without calling an engineer, so a static build is under-kill.
Counting the dependencies
The build I shipped has zero runtime dependencies. Not few: zero. The front end is React with GSAP for motion, loaded as plain production files. The compiler is a development tool that never ships. The build step is a small script I wrote, and the admin covers pages, blog, media, leads, team and settings behind eighteen distinct permissions, so an editor can be given exactly what they should touch and nothing else.
There is no dependency tree to audit, because there is no dependency tree. Nothing in it can be deprecated by a third party who changed direction. The security surface is the code I wrote and the server it sits on.
That is Lampstand Education Consult, and it is the reason I can describe the trade-off precisely instead of theoretically. The build corresponds to a mid-sized engagement, and I still operate it.
Why not a static site generator
Fair question, and I considered it seriously. Astro would have handled the six content documents well.
Two reasons it was not the answer. The first is the one above: a generator gives an editor a Git repository, and the client needed real editing with roles, not a pull request. The second is that I wanted to hand over something whose every moving part I could explain, and adding a framework to avoid writing a few hundred lines is a trade I did not want to make on a system I was going to be responsible for.
That is a judgement, not a rule. On a bigger content operation I would reach for the generator without hesitating.
What custom actually costs you
I would rather be straight about the downsides, because they are real and permanent.
You lose the ecosystem. Every feature that would have been a plugin is now a decision and some hours. You lose the hiring pool, because any competent developer can pick up WordPress and yours needs somebody who reads code. You lose the option to buy your way out of a problem at 4pm on a Friday.
What you buy in exchange is a surface small enough that very little can go wrong on its own. Whether that is a good trade depends entirely on the change rate, which is why the table above starts there.
Ask how often you actually changed something
One question, and be honest rather than aspirational about the answer.
“In the last twelve months, how many times did somebody need to change something that a developer could not have done in an hour?”
If the answer is dozens, you want WordPress and you want it now. The ecosystem is worth every penny of its overhead and I will happily build it.
If the answer is two, and both were content edits, you have been paying a platform tax for options you never used. That is the case where custom stops being an indulgence and starts being the cheaper thing over five years.
Whichever way you go, ask for the change rate to be written down before anyone chooses a platform. Half the WordPress builds I inherit were specified by someone imagining a publishing operation that never materialised, and the maintenance bill has been arriving every month since.