WordPress vs Custom React: The Real Cost

Most WordPress versus React comparisons argue about features. The question business owners actually ask is different: what does this thing cost me over the next three years, not on day one?

We are going to build that model with you. Before we do, one thing has to be said plainly, because the original version of this post did not say it.

The numbers in this article are assumptions, not measurements. We did not survey vendors. We did not audit a sample of invoices. Nobody has published a credible total cost of ownership study for small business websites, ours included. What follows is a spreadsheet you can fill in with your own quotes. Every figure we use as an example is labeled as an assumption, and you should replace all of them.

We also build with React and Next.js, which means we have a commercial interest in how this comes out. Read accordingly, and check our arithmetic.

The line items nobody puts in the quote

Whatever platform you pick, the real cost has more rows than the proposal does. Here is the full set.

WordPress line items

1. Initial build or theme customization, paid once, repeated at each redesign.
2. Hosting that runs PHP and a database. Cheap shared hosting and managed WordPress hosting are different products at different prices.
3. Plugin and theme licenses, renewed annually, one renewal date per vendor.
4. Update and patch labor. Core, plugins, and themes ship updates continuously. Somebody applies them, and when a security advisory lands, somebody applies it that day.
5. Conflict debugging. Plugins are written by different people. Sometimes an update to one breaks another.
6. Performance work. Caching configuration, image handling, database cleanup, script auditing.
7. The redesign cycle. Themes and page builders age. At some point the cheapest path forward is to rebuild.

Custom React and Next.js line items

1. Initial build. This is the big one and it is bigger than the WordPress equivalent.
2. Hosting. Static output on a CDN platform is inexpensive at small business traffic, and free tiers cover a lot of sites.
3. Dependency updates. A few hours a year on a well-built project.
4. Developer time for any structural change, including content changes if you did not add a CMS.
5. A headless CMS subscription, if your team needs to edit content without a developer. Leave this out and you have moved a cost, not removed it.

Note that item 5. It is the row most React advocates quietly drop, and it is where the "no maintenance" story goes soft.

The model

Three-year cost equals the initial build, plus 36 months of hosting, plus 3 years of licenses, plus the annual maintenance hours multiplied by your developer's rate, plus a rebuild if one falls inside the window.

That is the whole model. It is not complicated. What makes it useless in most articles is that the inputs are invented, so let us invent them out loud.

A worked example, with the assumptions stated

Assume a ten-page business site, one location, a contact form, a blog that gets a post or two a month, and no e-commerce. Assume the following, all of which are guesses that you should overwrite with real quotes:

• Your developer or agency bills at a single blended hourly rate.
• Managed hosting for the WordPress build, not the cheapest shared plan.
• Roughly half a dozen paid plugins on annual renewal.
• Someone applies WordPress updates monthly and responds to security advisories out of band.
• The WordPress theme or builder needs a significant rebuild inside the three-year window. This is the single largest swing factor in the entire model.
• The custom build is statically generated, deployed to a CDN, with no runtime server.
• Content edits on the custom build go through a developer, because we did not budget a headless CMS.

Fill those seven rows in and the picture that usually emerges is this: WordPress is cheaper to start and more expensive to keep, custom is more expensive to start and cheaper to keep, and the crossover point depends almost entirely on two variables. Those two variables are your maintenance labor rate and whether a rebuild lands inside your window.

That is the honest output of this model. It is not a number. It is a shape.

Where the model breaks

If nobody maintains the WordPress site, the maintenance cost is zero. Plenty of businesses simply do not do the updates. The cost does not vanish, it converts into risk, and risk does not show up in a spreadsheet until the day it does. We are not going to pretend we can price that for you.

If your team needs to edit content, custom code gets more expensive fast. Every text change that costs a developer twenty minutes is a real line item. Over three years, a marketing team that publishes weekly can spend more on developer time than the WordPress licenses ever cost.

Agency rates vary by a factor of five. Any total we published would be a fiction about your market.

The redesign assumption dominates everything. Assume no rebuild in three years and the two paths land close together. Assume a rebuild and WordPress looks expensive. That single assumption, not the platform, drives the conclusion. Be suspicious of anyone who buries it, and be suspicious of the earlier version of this post, which did exactly that.

The claim we are removing

An earlier version of this article included an "opportunity cost nobody calculates" section. It argued that if your WordPress site scores poorly on Lighthouse and a competitor's React site scores well, the competitor outranks you and takes your customers.

We are cutting that section, because we cannot support it. We have never measured a ranking change or a revenue change attributable to a platform migration, for a client or in a study. Google has said page experience signals are used in ranking, but they are one input among many and they do not outrank relevance. Presenting an unmeasured revenue loss as a cost line was the least defensible thing in the original post.

There is also a finding that runs the other way, and it belongs here rather than in a footnote. In our AI visibility study, 368 sites were analyzed and 92 lost at least one answer-critical element between the rendered page and the raw HTML. By platform, WordPress was 37 of 139, and other or custom builds were 34 of 107. Wix was 1 of 35 and Webflow was 1 of 15. Custom builds were the worst-performing group, mostly because a client-rendered React application serves an empty shell to any crawler that does not run JavaScript. If you buy custom code and the team does not pre-render, you can pay more and end up less visible. That is a cost too.

So read the number correctly. It says custom is worst in practice, not worst in potential, and those are different claims. The builders have a high floor: they server-render by default, so the median site is safe without anyone thinking about it. You also cannot climb past their ceiling. Custom has the lowest floor and the highest ceiling. An unguarded client-rendered app that ships an empty shell is the worst outcome in our data. A server-rendered or statically generated custom build is the best outcome available to anyone, because you own the rendering path instead of inheriting it.

We are not asking you to take that on faith. This site is custom Next.js. It scores 100 out of 100 on our own deep scan and 10 out of 10 on AI readiness, and you can run both yourself. No builder can be instructed to do that.

The honest decision rule: choose custom when you will actually do the work, and prove it with a scan. Choose a builder when you will not, because a high floor beats a ceiling you never climb.

What each platform is really buying you

WordPress buys you editorial independence and a large hiring pool, and charges you in ongoing maintenance and attack surface.

Custom React and Next.js buys you control, a small maintenance surface, and no plugin update treadmill, and charges you up front and every time you need to change something structural.

Neither is a moral position. They are different payment schedules for different constraints.

When WordPress is still the right call

Your team publishes often and needs a visual editor. You need WooCommerce and its inventory and shipping ecosystem. Your budget is small and you need to be live now. In those cases WordPress is not a compromise, it is the correct engineering decision, and we will tell you so.

Do this before you spend anything

Run your current site through our free SEO audit and see what is actually wrong with it. A surprising number of sites we look at do not need a rebuild. They need a caching layer, compressed images, and someone to fix the template.

Then take the line items above, put your own quotes in them, and do the arithmetic yourself. If you want us to check your math, including the scenario where you keep what you have, book a consultation. We do not need this to come out in favor of a rebuild.