Do You Need a CMS? WordPress vs Headless vs No CMS for Service Businesses

Somewhere in every website sales call, the question comes up: "Is it built on WordPress?" Sometimes it's asked with hope, sometimes with dread. Both reactions are usually secondhand. Someone got burned by a hacked site, or someone was told WordPress is the only serious option, and the opinion stuck.

So let's answer the underlying question properly: do you need a CMS at all? Not "which CMS." Whether the thing itself earns its keep on a service business website. If you want a second opinion on the site you already have, our free website audit covers this exact question along with speed and conversion.

What a CMS actually does, and what it costs you

A CMS (content management system) is software that lets non-developers change a website. Log in, type in a box, hit publish. WordPress is the biggest one; it powers about 43% of all websites according to W3Techs. Squarespace, Wix, and Webflow are CMSes with page builders attached.

That editing power is the product. Everything else a CMS ships with is the price of the product:

• A server that assembles your pages on demand, which is slower than serving finished pages
• A database, an admin panel, and a login screen that attackers can find at the same URL on every install
• A plugin layer, because the core system never does everything, and every plugin is someone else's code running inside your site
• An update treadmill: core updates, theme updates, plugin updates, PHP version bumps, and the hosting bill under all of it

None of that is a criticism yet. It's a trade. The question is whether you use the editing power enough to justify carrying the machinery.

The honest math for a service business site

Here is what we see across roofing, HVAC, plumbing, and electrical sites: the owner edits the website roughly never. After launch, a typical service business site changes when a phone number changes, when a new service launches, when photos need refreshing, and when a blog post goes up. That's a handful of edits a quarter, and in practice the agency or the marketing person makes them anyway.

Meanwhile the CMS bill runs every month whether you edit or not:

• WordPress care plans (updates and security monitoring) run $50 to $150/mo. That's $600 to $1,800 a year for maintenance on software you barely touch.
• WordPress hosting worth using runs $10 to $40/mo. Static and edge hosting for custom sites runs $0 to $20.
• A typical contractor WordPress site carries 20 to 30 plugins. Each one is an update to track and a potential hole.

Read that stat carefully, because it cuts both ways. WordPress core is genuinely well-secured: two vulnerabilities all year. The plugin layer around it is where the risk lives, and Patchstack measured the median time from disclosure to first exploitation attempt at about five hours. If nobody is watching your plugin stack daily, you are effectively unpatched. That is what the $50 to $150/mo care plan is actually for.

The three ways to build a website in 2026

The terminology gets sloppy in sales conversations, so here are the three real options, with the labels developers use:

Traditional CMS

WordPress, Squarespace, Wix. One system stores your content, renders your pages, and hosts the admin panel. Easiest to self-manage, heaviest to carry.

Headless CMS

The content lives in a separate system (Contentful, Sanity, or WordPress itself running in "headless" mode) and a custom-built front end pulls it in through an API. You keep an editing dashboard but the public site is fast, modern code. This is the standard architecture for content-heavy companies with in-house editors.

Custom-coded with a content feed

The site itself is code, built and deployed like software. There is no admin panel bolted to it. Content that changes often, like blog posts and project galleries, lives in a small database and flows in through a lightweight pipeline. This is what we build, and it borrows the best part of the headless pattern without paying for a full CMS subscription nobody will log into.

Do you need a CMS? Four questions

Answer these honestly and the decision makes itself.

1. Who edited your current site in the last 90 days? If the answer is "nobody" or "my marketing person," you are not the audience a CMS is built for. If you personally published something last week, you are.

2. How often does content ship? Daily or several times a week: you need a real editing dashboard, either a traditional CMS or a headless one. A few posts a month: a content pipeline handles that without a CMS attached to your site.

3. Do you sell products online? An actual store with a cart changes the answer. WooCommerce on WordPress or Shopify are the sane paths, and we'd point you to them.

4. Who do you want responsible when something breaks? With a self-managed CMS, that's you at 9pm when a plugin update takes down the contact form. With an agency-built custom site, it's the agency, and there are far fewer ways for it to break in the first place.

Is WordPress outdated in 2026?

As a piece of software, no. WordPress core is actively developed, patched fast, and runs a meaningful chunk of the internet. Calling it dead is lazy.

As a default choice for a 15-page service business website, yes, it's showing its age. WordPress was designed in 2003 for a world where the server assembled every page at request time and the blog was the website. The modern pattern, where pages ship as finished code from an edge network near the visitor, did not exist yet. That pattern is why a well-built custom site posts load times a plugin-loaded WordPress install has to fight for. Our own homepage scores 92 on Lighthouse's mobile test with a 2.6-second LCP, and there is no caching plugin, security plugin, or optimization plugin involved, because there are no plugins.

Speed is not cosmetic. Google's Core Web Vitals threshold for LCP is 2.5 seconds, it feeds into rankings, and it is where most WordPress sites bleed. We wrote up how much of local SEO comes down to boring technical health in our contractor SEO guide.

Why people are actually moving away from WordPress

The pattern in the horror stories is consistent, and it is rarely WordPress core's fault:

• The plugin treadmill. The site launches with 12 plugins and accumulates 25. Two go abandoned by their developers. One of those is how the site gets popped.
• The mystery slowdown. Each plugin adds queries and scripts. The site that loaded in 2 seconds at launch loads in 6 by year three, and nobody can say which plugin did it.
• The ransom maintenance bill. $100/mo forever, with zero improvements attached, purely to keep the machinery from rusting.
• The page builder lock-in. Sites built in Divi or Elementor are portable in theory; in practice the next developer quotes a rebuild.

Notice that every one of these is a cost of the machinery, not of the editing power. The owners in these stories were not heavy editors. They were carrying a publishing platform they didn't publish with.

When WordPress is still the right call

We build zero-CMS sites, and we'd still steer you to WordPress or a cousin in three situations:

• You publish constantly, in-house. A team shipping posts and landing pages weekly needs a dashboard, and WordPress's editor is mature and familiar.
• You run a store. WooCommerce and Shopify have solved a thousand ecommerce problems you do not want solved custom.
• You want to own every edit yourself and pay nobody. A DIY owner comfortable with updates who edits monthly is exactly who WordPress serves. Go in eyes open about the maintenance, and it's a fine deal.

And if you love the WordPress editor but hate the slow front end, headless WordPress is a real middle path: keep the dashboard, replace the public site with modern code. It costs more to build and suits bigger content operations, but it's a legitimate architecture, not a hack.

What we build instead, specifically

Our client sites are custom-coded and deployed to an edge network, the same architecture pattern (minus the enterprise price tag) that companies moved to when they went headless. Blog posts and project photos live in a database and flow onto the site through a content pipeline, so the content that changes often still updates without a developer touching code. And since no admin panel is attached to the site, there is no login page for anyone to attack.

What that means in practice for a client:

• Edits are a message to us, and they ship same-week. You are not paying a care plan to keep software patched; content updates are part of the plan you're already on.
• The site is as fast in year three as at launch. Nothing accumulates.
• The attack surface is close to zero. No login page, no plugin CVEs, nothing for the 11,334 vulnerabilities a year to land on.

The trade is real and worth naming: you cannot log in and restructure a page yourself at midnight. For owners who were never going to do that, it's a trade that costs nothing. For owners who want that power, see the WordPress section above; we mean it.

The lock-in question, answered straight

"If my agency builds it custom, am I stuck with them?" Fair question, and the answer should be checked before signing with anyone, us included.

You should own the domain, and the code should be exportable. A custom-coded site is a folder of standard web code any competent developer can pick up; there is no proprietary page builder underneath it. Your content lives in a database you can export as a spreadsheet. Compare that honestly with a Divi or Elementor site, where "you own it" is technically true and practically means paying someone to untangle it. Lock-in is about how your site is built and who holds the keys, and it exists on every platform. Ask the same three questions of any builder: who owns the domain, can I get the code, can I export the content.