Custom CMS vs WordPress: An Architecture Decision Guide

Choose WordPress when your site is mostly content and your team needs to publish quickly; choose a custom CMS when the content is only one part of an application with its own data, rules and integrations. Most brochure sites, blogs and marketing sites are better off on WordPress, managed well. Most internal tools, SaaS products and systems with complex records are better off with a custom build on something like Laravel or an edge stack such as Cloudflare Workers, Hono and D1.

I've built on both. This site runs on a custom Workers, Hono and D1 stack, and in my work as an IT manager I've also looked after WordPress sites. Neither is the "right" answer in general. This guide covers WordPress's real market position as of September 2026, what the latest plugin security data says, headless WordPress as a middle path, the main custom options, total cost of ownership, and a decision table you can use in a planning meeting.

Key takeaways

• WordPress is the default for a reason. W3Techs puts it on 40.2% of all websites and 58.7% of sites with a known CMS, as of 25 September 2026.
• The security risk sits in plugins, not core. Patchstack counted 11,334 new WordPress ecosystem vulnerabilities in 2025. 91% were in plugins and only six were in core.
• Speed of patching matters more than platform choice. Patchstack reports a weighted median of five hours to first exploit for heavily exploited vulnerabilities, and 46% had no patch at disclosure.
• Headless WordPress is a real middle option. Keep the familiar editor, serve the front end from your own code through the REST API or WPGraphQL.
• Custom isn't automatically safer or cheaper. You trade plugin risk for your own code's risk, and you pay for development and upkeep yourself.

How dominant is WordPress in 2026?

WordPress is still the most widely used CMS by a wide margin. According to W3Techs' CMS usage survey, checked on 25 September 2026, WordPress runs on 40.2% of all websites it monitors and holds 58.7% of the CMS market. The next three, Shopify, Wix and Squarespace, sit at 5.4%, 4.2% and 2.4% of all websites.

That matters for practical reasons, not bragging rights:

• Hiring is easier. Developers, designers and content editors who already know WordPress are easy to find.
• Hosting is a commodity. Almost every host supports it. The official requirements recommend PHP 8.3 or greater, MySQL 8.0 or MariaDB 10.11 or greater, and HTTPS support.
• Most problems are already solved. Forms, SEO metadata, multilingual content and e-commerce all have established plugins.

The original version of this post said WordPress was "over 40% of the web." That's still accurate, but only just, so it's worth checking the live number before quoting it in a proposal.

What does the plugin security data actually show?

WordPress core is in good shape, and most real-world risk comes from plugins and themes. Patchstack's State of WordPress Security in 2026 whitepaper, which covers vulnerabilities disclosed during 2025, reports:

• 11,334 new vulnerabilities in the WordPress ecosystem in 2025, a 42% increase over 2024.
• 91% in plugins and 9% in themes. Only six were reported in WordPress core, all rated low priority.
• 46% had no patch from the developer by the time they were disclosed.
• 17% carried a high risk of mass-scale exploitation, according to Patchstack's rating.
• Five hours was the weighted median time to first exploit for heavily exploited vulnerabilities.
• Only 26% of attacks were blocked by hosting providers' defences in Patchstack's testing.

Two lessons follow. First, a WordPress site's risk is roughly proportional to how many third-party plugins it runs and how well they're maintained. A site with a lean, well-chosen plugin list is a very different proposition from one with forty plugins nobody has reviewed in a year. Second, you can't rely on the host alone. Since WordPress 5.5, administrators can turn on auto-updates plugin by plugin, and WordPress runs those checks twice a day by default. With a five-hour median window to first exploit and nearly half of vulnerabilities unpatched at disclosure, auto-updates help but don't close the gap. You also need a small plugin footprint and a way to remove or virtually patch a plugin quickly.

The original post claimed a custom CMS gives "maximum security" because it has no publicly known plugin vulnerabilities. That's only half true. Obscurity reduces automated mass attacks, but your own code can still have SQL injection, broken access control or outdated dependencies. Custom is safer only if it's built and maintained carefully.

Is headless WordPress a good middle path?

Yes, when you want WordPress's editor and your own front end. In a headless setup WordPress stores and manages content, and a separate application renders the pages. The WordPress REST API handbook describes this directly: you can "bring your WordPress content into completely separate applications," and any language that can make HTTP requests and read JSON can use it.

If you prefer GraphQL, WPGraphQL is the common choice. Its WordPress.org listing shows 30,000+ active installations as of September 2026 and says it's becoming a Canonical Plugin, which signals longer-term support from the WordPress project.

What headless gives you:

• Editors keep the WordPress admin they already know.
• The public site can be static or edge-rendered, which usually means a smaller attack surface on the public side and more control over performance.
• The same content can feed a website, an app and other systems.

What it costs you:

• Two systems to run. You still patch WordPress and its plugins, and you now maintain a front end as well.
• Lost conveniences. Many themes and page-builder plugins assume WordPress renders the page. Previews, forms and SEO plugins often need extra work.
• More developer time. A headless build is closer to a custom project than to a theme install.

Headless tends to make sense for content-heavy sites with a development team, or where performance and multi-channel publishing justify the extra moving parts. For a small business with no developer on staff, it usually adds cost without enough benefit.

What are the realistic custom CMS options?

A custom CMS means you own the data model, the admin and the rendering. In practice there are two main routes I'd consider for most projects.

Laravel (PHP)

Laravel is a mature PHP framework with authentication, queues, an ORM and first-party starter kits. It publishes a clear support policy: every major release gets 18 months of bug fixes and two years of security fixes. Laravel 13 was released on 17 March 2026, requires PHP 8.3 or later, and receives security fixes until 17 March 2028. Laravel 12 stopped receiving bug fixes on 13 August 2026 and gets security fixes until 24 February 2027. That predictable cadence is useful when you plan maintenance budgets: expect a major upgrade roughly every year or two.

Laravel suits applications with complex relational data, role-based access and back-office workflows, like an HR system or an ERP-style module. I cover that kind of project in the HRIS implementation guide. It runs on ordinary VPS or managed PHP hosting, so the hosting model is familiar.

Edge stacks: Cloudflare Workers, Hono and D1

This is how this site is built, which I described in building a portfolio site with Cloudflare Workers, Hono and D1. The code runs on Cloudflare's network, Hono handles routing, and D1 provides a managed SQLite database. Per Cloudflare's Workers pricing page, as of September 2026:

• The Free plan allows 100,000 requests per day with 10 ms of CPU time per invocation.
• Workers Paid has a $5/month minimum, includes 10 million requests and 30 million CPU milliseconds per month, then charges $0.30 per additional million requests.
• "There are no additional charges for data transfer (egress) or throughput (bandwidth)."

For a read-heavy content site that's a very low running cost, with no server to patch. The trade-offs are real, though. You write the admin panel yourself, D1 has a 10 GB per-database cap, and the runtime isn't Node.js, so some libraries won't work. My Cloudflare D1 guide covers those limits in detail.

WordPress vs headless WordPress vs custom CMS: comparison table

What does total cost of ownership look like?

Total cost of ownership is the build cost plus everything you pay to keep the site safe and useful for the next three to five years. Licence and hosting prices are usually the smallest part. I'm not going to quote hourly rates or project budgets, because they vary too much by country and team, but the cost categories are predictable:

• Build. WordPress is cheapest when a theme and standard plugins cover your needs. It gets expensive once you fight the platform with heavy customisation. Custom builds cost more up front because every screen is built.
• Premium plugins and themes. Many are sold as annual licences, so they recur. Patchstack's report also found premium components had three times more known exploited vulnerabilities than free ones, so paying for a plugin doesn't make it safer. Budget for review, not just renewal.
• Hosting. Traditional WordPress and Laravel need a PHP host or VPS that someone patches. A Workers site starts on a free plan and moves to a $5/month minimum on Paid.
• Security and updates. On WordPress, this is ongoing plugin and core updates, testing after updates, and possibly a virtual patching service. On a custom build, it's dependency updates and framework upgrades, such as moving between Laravel majors inside the two-year security window.
• Knowledge risk. A custom CMS written by one developer becomes expensive when that person leaves. Documentation, tests and a readable codebase are part of the cost, not extras.
• Performance work. Plugin-heavy WordPress sites often need caching and optimisation to pass Core Web Vitals. Custom sites need it too, but you start with less weight. See Core Web Vitals and SEO optimisation for what to measure.

The honest summary: for a standard content site, WordPress almost always has the lower total cost. A custom CMS earns its higher cost only when it replaces workarounds you'd otherwise pay for every year, or when the site is really an application.

When does each option win?

WordPress wins when

• The site is mostly pages, posts and forms, like a company site, blog, portfolio or news site.
• Non-technical staff need to publish daily without a developer.
• You need to launch in weeks, and a standard theme covers the design.
• You can commit to a small plugin list and regular updates.

Headless WordPress wins when

• Editors are attached to WordPress, but the front end needs custom performance or design.
• The same content feeds several channels.
• You have developers to run a separate front end long term.

A custom CMS wins when

• The "content" is really records with rules: employees, orders, bookings, approvals.
• You need deep integrations with payment gateways, ERPs or internal APIs.
• Access control is complex, with different roles seeing different data.
• You'd otherwise stack many plugins to approximate one business process.
• You have, or can hire, developers to maintain it for years.

The original post framed this as small business versus enterprise. Size isn't really the test. A large company's marketing site can be perfectly served by WordPress, and a small startup's product might need custom code from day one. The test is what the system has to do.

A decision checklist before you commit

1. Write down the content types and workflows. List every type of record, who creates it, who approves it and where it goes. The methods in system analysis techniques for IT professionals help here.
2. Count the plugins you'd need. If the list is short and well known, WordPress is likely fine. If it's long or includes niche plugins with few installs, treat that as a warning.
3. Check each plugin's maintenance. Look at the last update date and support activity on WordPress.org before you install it.
4. Decide who patches, and how fast. Given Patchstack's five-hour weighted median to first exploit, name a person and a process for updates, not just a host.
5. Map integrations. Note every external system the site must talk to and whether an existing plugin actually covers it.
6. Estimate three to five years of cost, including licences, hosting, updates and framework upgrades, not just the build.
7. Plan for the developer leaving. For custom builds, require documentation, tests and a handover. For WordPress, avoid custom code hidden in a theme.
8. Plan the exit. Make sure you can export content in a usable format from whichever platform you pick.

FAQ

Is WordPress still worth using in 2026?

Yes, for content-focused sites. W3Techs reports WordPress on 40.2% of all websites as of 25 September 2026, so skills, hosting and plugins are easy to find. It's a weaker fit when the site is really an application with complex data and business rules.

Is WordPress insecure?

Core isn't the main problem: Patchstack found only six core vulnerabilities in 2025, all low priority. The risk comes from third-party components: of 11,334 new vulnerabilities, 91% were in plugins and 9% in themes. A lean plugin list, auto-updates and fast patching reduce that risk a lot.

Is a custom CMS more secure than WordPress?

Not automatically. It avoids mass attacks aimed at popular plugins, but your own code can still have vulnerabilities, and its dependencies still need updates. It's more secure only when it's built with secure defaults, such as prepared statements and proper access control, and maintained over time.

What is headless WordPress?

Headless WordPress uses WordPress only to store and edit content. A separate front end fetches that content through the WordPress REST API or a plugin such as WPGraphQL and renders the pages. You keep the editor but take on a second system to build and maintain.

Should I use Laravel or Cloudflare Workers for a custom CMS?

Choose Laravel for complex relational data, back-office workflows and a large PHP ecosystem on familiar hosting. Choose Workers with Hono and D1 for read-heavy sites where low running cost and no servers matter, as long as your data fits D1's limits and your team is comfortable with TypeScript.

If you're weighing WordPress against a custom build for a specific project, you can get in touch here and I'll give you a straight opinion.