Stop thinking WordPress is cheap. It's expensive — just in a different way.
You've probably heard this one: "WordPress is cheaper, Next.js is for big projects." People repeat it mindlessly. A developer tells it to a client, the client repeats it to the next developer — round and round. The problem is, it's simply wrong.
From my experience building websites and applications — including a full marketplace with its own billing system on Next.js and Medusa.js, the handmade craft platform artovnia.com — I know one thing: WordPress isn't cheap. It's expensive in a different way. Quietly, so you don't notice right away.
On top of that, the alternatives are rarely known to anyone outside the developer world. Clients don't know other stacks. WordPress is something most people have heard of: "I want a website — I heard that website equals WordPress." The Snickers bar of CMS. And so the cycle continues.
What does it actually cost to run a WordPress site?
The short version: WordPress is free like a printer. The device costs next to nothing, but for the next few years you're paying a fortune for ink.
Hosting — cheap hosting is a recipe for a site that takes 4 seconds to load and falls over at 50 concurrent users. To make it work properly, you need managed WordPress: Kinsta, WP Engine, Cloudways. You're starting at dozens of dollars per month — from day one, whether you have traffic or not.
Premium plugins — SEO plugin, page builder, forms, cache, backup, security, GDPR... Each one is several dozen dollars per year. Stack 8–10 plugins together and suddenly you're paying like a proper SaaS subscription — for things that simply don't exist as a problem in a modern stack.
Technical debt and updates — WordPress is a moving target. PHP moves up, the theme isn't compatible, a plugin stopped being developed, two plugins start conflicting with each other. This isn't a pessimistic scenario — it's the normal lifecycle of a WP project. Someone has to deal with it. That someone is either you, or a developer you're paying an hourly rate to fight fires.
Slow WordPress — where the performance problem actually comes from
The PHP + MySQL architecture handles itself reasonably well with proper caching. The real performance killer is page builders: Elementor, Divi, WPBakery. They generate a massive DOM, load dozens of CSS and JS files, block rendering. The result: LCP above 3 seconds, high TBT, CLS on font and image loading. You can fix it — but you need WP Rocket, CDN configuration, manual asset optimization, and several days of work. And again: someone has to deal with it.
WordPress security — why it's a real problem
WordPress powers over 40% of all websites in the world. What does that mean? That it's the number one target for automated attacks. Every bot scans the internet for /wp-admin and /wp-login.php. xmlrpc.php — an endpoint active by default — is regularly used for brute-force and DDoS amplification attacks. I know because I see it in the logs of my own sites and applications, even though most of them run on Next.js.
But the biggest problem is plugins. In 2024, 7,966 new vulnerabilities were found in the WordPress ecosystem — a 34% increase over the previous year. 96% of them were in plugins. One in three of those flaws remained unpatched at the time of public disclosure. 43% were exploitable without any authentication — the attacker doesn't need a password, an account, anything. Just know the vulnerability and run a script.
These aren't exotic edge cases. Critical vulnerabilities regularly hit plugins with hundreds of thousands of active installations — contact forms, page builders, backup tools. Things you have on every site.
And here's the core of the problem: you don't control when the plugin author ships a patch — or whether they ever will. In 2024, 827 plugins and themes were abandoned. If one of them is on your site, the vulnerability stays open forever.
Next.js isn't magically secure — badly written code is badly written code, regardless of the technology. But the automated attacks that scan the internet for WordPresses every day simply have nothing to find here. No predictable endpoints, no plugin ecosystem with unpatched CVEs. I write in detail about how to approach security in Next.js and what to watch out for during development in this article.
Next.js as a WordPress alternative — what you gain and what it costs
The catch is that Next.js runs on a completely different cost model. Most people only look at the build cost — not the total cost of ownership.
Hosting at $0 — Vercel Hobby plan is free and sufficient for the vast majority of local businesses, company websites, portfolios, and landing pages. You start paying at a scale most small projects will never reach.
CMS at $0 — Sanity's free plan supports up to 3 users, unlimited documents, and 10 GB of storage. You're starting with a stack that costs $0 per month for a long time before you exceed any meaningful limit.
Architecture that makes sense — Next.js generates pages at build time or caches them at the CDN level. The user gets ready-made HTML served from the edge node closest to their location — no PHP, no database queries, no generating pages on the fly. TTFB under 100ms is simply the default behavior of a well-written application here.
Smaller attack surface — No /wp-admin accessible to the entire internet. No xmlrpc.php. No plugin ecosystem with unpatched vulnerabilities. The automated attacks scanning the internet for WordPresses simply have nothing to find here.
Predictability — you update dependencies when you want and test locally before anything hits production. No "plugin update that breaks something on Saturday before the campaign."
I describe costs of modern website in detail here:
How Much Does a Modern Website Cost in 2026?
"But the client won't be able to edit the site"
The most common argument for WordPress. And it's a weak one.
Modern headless CMSes have interfaces simpler than WordPress, not harder. The client clicks, edits, publishes — without touching any code.
You can go even further. By building schemas in Sanity or Payload, you design the editing panel exactly around the client's needs. Only the fields they'll actually change. In exactly the right order. With names and descriptions that make sense to them. Without options they can accidentally break.
I do this myself — a few days of work configuring schemas pays off in zero phone calls asking "how do I change this." WordPress gives you a ready-made panel for everyone. A headless CMS gives you a tool to build a panel for that specific person.
WordPress vs Next.js — performance in numbers
A well-written Next.js application should achieve:
- LCP under 2s (aim for 1–1.5s)
- CLS close to 0
- TTFB under 200ms with edge deployment
These numbers have real meaning. Google uses Core Web Vitals as a ranking signal. A slow site drops in search results.
Achieving these results on WordPress is possible — but it requires proper caching, CDN, image optimization, eliminating render-blocking scripts, and dropping heavy builders. In practice: several days of work and several paid tools. On Next.js, most of these things come from the architecture, not from patching bad default settings.
When WordPress honestly makes sense
I'm not here to tell you WordPress is always the wrong choice. It has its use cases:
- A client who's been living in WP for years and absolutely doesn't want to learn anything new
- A blog with a massive post history already on WordPress — migration might cost more than it's worth
- A budget of around $200–300 for a site with a ready-made theme — Elementor will do the job and no one's pretending it's architecture built to last
- A project where the client needs full independence with no technical support and knows WP inside out
Outside those cases... Next.js wins.
Finally
Next time you hear "let's do it on WordPress, it's cheaper" — ask: cheaper for how long? For whom? Has anyone calculated the total cost of ownership over 3 years?
Next.js + headless CMS stack: free hosting to start, free CMS to start, a tailor-made editing panel, zero plugins to maintain, zero surprises after updates, architecture that won't collapse under heavier traffic.
The cost is a few days of solid development — instead of years of subscriptions and fighting fires.
Custom doesn't mean expensive. It means designed for you — instead of adapting yourself to the limitations of a tool built for everyone and for no one in particular.
Personally, I prefer freedom and dedicated solutions.