WordPress served a purpose. But for most small business marketing sites, the overhead isn't justified by the use case. Here's the honest accounting of what running WordPress for client sites actually costs — and what we use instead.

The call that finally changed our mind

It's 11:15 on a Tuesday night. A client — a small physiotherapy practice, five staff, a website they're proud of — is messaging because their homepage has gone blank. Not slow. Blank.

We've had this call in one form or another more times than we'd like to count. A WordPress core update pushed through, something conflicted with the page builder plugin, and the site is down. Our developer spends two hours debugging a plugin dependency tree that has nothing to do with the work we were ever hired to do.

That's the moment. Not the first time it happened — the first time, you chalk it up to bad luck. But by the fourth or fifth time, you start asking whether the platform is the problem.

How WordPress became the default

It's worth being fair about this. WordPress didn't become dominant by accident. It democratised web publishing at a time when the alternative was hiring someone to write HTML by hand. The plugin ecosystem was genuinely powerful. Themes made it accessible. For a long time, recommending WordPress to a small business client was the most rational thing an agency could do.

Then the calculus shifted.

The plugin ecosystem grew to 60,000+ plugins of wildly varying quality and maintenance status. WordPress core updates and plugin updates stopped coordinating. The admin interface — designed for bloggers in 2003 — never fundamentally changed, even as client expectations for simplicity did. And because WordPress powers 40%+ of the web, it became the most targeted CMS on the internet by volume. Keeping a client site secure required active maintenance: updates, security plugins, monitoring, backups.

The tool didn't get worse. The alternatives got better, and the overhead accumulated.

What "WordPress for a client" actually costs an agency

These are not hypothetical costs. This is the real accounting.

Plugin maintenance. Every plugin is a dependency. A site with 20 plugins has 20 relationships to maintain — each with its own update cycle, its own breaking changes, its own compatibility surface with WP core. This is not a one-time setup cost. It compounds annually.

Hosting overhead. A PHP application server requires more configuration and maintenance than static hosting. Most small business clients are on shared hosting, which compounds the performance and security issues. Every major vulnerability disclosure requires coordinated action across your entire client portfolio.

Security surface. WordPress sites are the most targeted CMS on the internet by volume. Malware injections, brute-force login attempts, plugin vulnerabilities, outdated PHP versions. Keeping a client site clean is an ongoing job.

The reactive support tax. If a developer spends an average of two hours per client site per quarter on WordPress-related issues — plugin conflicts, update breakages, security cleanup — and they have 20 client sites, that's 160 hours per year. Roughly a month of developer time. Almost none of it was ever scoped into the original engagement.

Client confusion. WordPress admin access is effectively all-or-nothing. Give a client admin credentials — and most clients ask for admin credentials — and you've given them access to plugin settings, theme editors, widget areas, and the file editor. One wrong click breaks the site in ways neither obvious nor easily reversible.

What small business clients actually need

Strip the problem back to its essentials. What does a small service business — a physio practice, a restaurant, a local retailer, a professional services firm — actually need from a website?

1. A fast-loading site that works on mobile
2. A simple editing interface: update text, swap images, add a page, without calling anyone
3. A way to capture leads — contact form, quote request, newsletter signup
4. Reliable hosting that doesn't require them to think about it
5. A domain that works

That's the list. Notice what's not on it:

• A PHP application running 24/7 on a server
• 30 plugins
• Database backups they have to configure
• A security plugin subscription
• An admin interface designed for a 2003 blogging workflow

Most small business WordPress sites exist in the gap between what WordPress provides and what the client actually needs. The features go unused; the overhead does not.

How SleekCMS handles the same use cases

We're not neutral here — we switched our agency's default stack to SleekCMS. Here's the direct mapping.

Fast site: Static HTML generated from content and templates, served from a global CDN. No PHP, no database queries at request time. Page load times are structurally faster — not as a result of optimization work, but as an inherent property of the architecture.

Simple editing: The SleekCMS editor is built around the content model. Editors see fields and blocks — the specific fields defined for their site — not an admin panel full of settings they shouldn't touch. Client gets access to what they need; developer controls what they can change.

Lead capture: Forms work with a single HTML attribute: data-sleekcms="contact". Submissions are captured, stored, and visible in the dashboard. Email notifications work out of the box. No Formspree subscription, no serverless function, no third-party service to maintain.

Hosting: SleekCMS generates and hosts the static site — CDN delivery included on every plan. Custom domain setup is three fields and a DNS record. No hosting account for the client to manage or accidentally cancel.

No maintenance tax: Static sites have no plugin ecosystem to maintain, no CMS core to update, no PHP attack surface at request time. The 11pm call becomes structurally impossible for a category of failure that used to be frequent.

The honest tradeoffs

We're not going to pretend SleekCMS replaces WordPress for every use case. It doesn't.

If a client genuinely needs WooCommerce or a complex e-commerce workflow, WordPress is probably still the right answer — or at minimum, the least-bad option. If they have a large existing WordPress installation with years of custom development, migration cost may not be justified. If they need a highly specialised plugin ecosystem — membership sites, event ticketing, LMS — WordPress may still be the most practical choice.

The argument is not "WordPress is bad." The argument is: for most small business marketing sites — sites that exist to present the business, capture leads, and be found in search — the overhead isn't justified by the use case. The features go unused. The maintenance does not.

What the switch freed up

Since moving our client default to SleekCMS:

• Reactive support hours dropped substantially. The category of failure that created those hours mostly disappeared.
• Scope conversations got simpler. "Maintenance retainer" stopped being a line item for straightforward marketing sites.
• Clients update their own content without calling in. The editor is simple enough that it actually gets used.
• We deliver projects faster. The setup overhead for a new client site is smaller.
• Managing a portfolio of 20 client sites feels different when none of them are WordPress.

The switch wasn't about the technology. It was about getting out of a support relationship that shouldn't have existed in the first place. Most client sites are content sites. They should be simple, fast, and maintainable by the client themselves.

If you're managing client sites and spending more time on WordPress housekeeping than on work that actually moves the needle — it's worth seeing what a different default looks like.

Originally posted at SleekCMS