The conversation you keep having
A small-business client lands in your inbox and the first line is some version of "I want a website like my last one." Sometimes they name WordPress directly. More often they describe it: a place they can log in and change the text themselves, and somewhere down the line they might want to add a thing.
You know WordPress from the inside. You've stood up installs, managed the plugin stack, and been the person who got the 11pm call when an update took a site white. You build in React alongside it. So this isn't a pitch about whether the newer tooling is real. You already know it is.
The decision is narrower than the stack wars make it sound. For this client, do you reach for WordPress or for a static Next.js site with a git-backed CMS? Not "which stack is better in the abstract." Nobody who has shipped on both thinks that question has an answer. The real question is which one fits the site in front of you.
I've settled on two questions that decide it, plus one part of the answer that changed recently enough that most of us haven't rewritten our talking points.
Two questions that decide it
For a small content-first site, the recommendation falls out of two yes/no questions, run in a specific order.
Question one: does the owner need to manage non-content functionality themselves, with no developer in the loop? A store they run day to day. Content gated behind a membership they administer. A booking calendar they adjust every week. Not "could they imagine wanting this someday." Do they need it now, and do they need to operate it without calling you?
Question two: is there someone technical who can do a one-time CMS setup and build the content model? That's you, or someone like you, for an afternoon at the start. Not ongoing support. Once.
The order is the point. Question one filters out the sites WordPress is genuinely built for before you bother with anything else. If the answer is yes, you're done: recommend WordPress. Its plugins do owner-run functionality and the static stack has no clean answer for it. Question two only matters for the sites where the static case could apply at all, so there's no reason to ask it first. Run them in that order and most calls are over before the second question.
The florist who runs her own bookings and takes payment through the site is a yes on question one. The accountant whose site is five pages and a contact form is a no, and now you're on to question two.
Why the second path holds up now
Two things used to make WordPress the only real option for a non-technical owner: they could edit the site in a browser, and there was a deep, cheap pool of people to change it. Both are solved now. Here's what changed, in the order that makes question two answerable in the client's favor.
The editing story
A git-backed CMS gives the owner browser editing that feels like editing a page. They open the site, change a headline or a paragraph inline, hit save. Underneath, the CMS writes that change to a markdown file, commits it to git, and the site rebuilds. To the owner it's a text box and a save button.
Tina and Keystatic both do this, both are Next.js-native. Keystatic is self-hostable with no per-user gate. Tina's hosted free tier has user limits before it becomes a paid plan — worth checking the current pricing page before you promise "free forever" to a client who's going to want five people editing next year. (I've been caught by that one.)
The structural part matters more than the interface. A bad content edit here is a bad sentence, and there's a full git history to revert it from. A bad content edit on WordPress can still be a white screen when a shortcode or a block fails, because the editor and the running site share the same box. On this stack they don't. It's content, not code, so it can't take the site down.
Maintenance: the cost nobody quotes
The real cost of a WordPress site was never the build. It's the entropy after: the plugin that breaks on the next update, the PHP version bump, the theme whose author disappeared, the security patch you apply or the site becomes an attack surface. You know this. You've lived it.
Picture the failure that actually kills small sites. Not a redesign. A plugin the owner forgot was installed, abandoned by its author two years ago, carrying a vulnerability that gets the site defaced on a Tuesday while nobody's looking. WordPress sites are the most-targeted surface on the web because they're the most common, and a forgotten plugin is a door you can't lock if you don't remember it's there.
A static site with no database and no admin login removes the whole category. Nothing to inject, nothing to brute-force, no plugin carrying a three-year-old CVE.
The maintenance you never do is the real line item on the invoice. It's just the one nobody quotes up front.
Who does the client call
Five years ago, anything past a content change needed a WordPress developer, and the argument for WordPress was that there were thousands of them and they were cheap. That was a real advantage and it deserves a real answer.
Here it is: a plain Next.js repo with a clear README is legible to any developer. Standard framework code, a large pool of people who can read it, a file at the root that tells any of them how the thing is put together. The client isn't locked to one person or one shop.
And a repo that's legible to a developer is legible to a coding agent too. That's the same property, pointed at a different reader, and it's what changed what "but what if I need something custom" costs to answer.
The reasons that were always there
Once the editing story and the change story are handled, the arguments the static approach always had finally get to count without caveat.
A static site is built once and served as finished HTML from a CDN close to the visitor. WordPress renders each page from a database on request, then people bolt on caching plugins to undo the damage — and the caching plugins become their own source of breakage. Pre-rendered pages are faster, and speed moves both search ranking and conversion. The fast version of a page makes more money than the slow version of the same page.
And the site is yours. A folder of markdown files and standard framework code. No proprietary page-builder, no CMS data model to be trapped inside, no database migration when you move hosts. In ten years the markdown is still markdown and the site still builds. Portability is a feature you only appreciate the day you need it.
What AI tools changed about "I need a plugin for that"
Start with why the plugin ecosystem existed at all. Commissioning custom functionality meant hiring a developer, and for a small-business budget that was often out of reach. A general-purpose plugin was the affordable alternative. Somebody had already built the contact form, or the calculator, or the integration, for everybody's version of the problem, and you configured it down to something close to what this client needed.
That's the trade a plugin is. It's the general solution. It carries far more code than any one site uses, it has its own update schedule and its own security surface, and it fits your client's actual need approximately, because it was never built for them. The trade made sense the whole time custom meant expensive.
But it doesn't anymore.
Now the client describes what they want to Claude Code or Codex and gets it built into this site, specific to this business. A contact form that routes submissions by topic: sales to one address, support to another, press to a third, because that's how this business is actually organized. A pricing calculator built around this business's real inputs, not a generic one bent to fit. The one third-party integration they actually use, wired directly, instead of a plugin that supports forty integrations and does theirs adequately.
Each of those is specific to one client. A plugin is the general version of each. What flipped is the price: the specific version now costs less time and money than the general one, which is the exact reversal that used to justify reaching for a plugin in the first place. No plugin overhead, no update cycle for code you didn't write and can't fully see. When the form needs to change, it's a change to this site's code, not a config screen inside a black box you're hoping the maintainer keeps alive.
The person commissioning this does not need to know how to build it. They need to know what they want. That has always been true of a client. They've always been the one who knows the business. What dropped is the barrier: from "hire a developer" to "describe what you want." The knowledge barrier fell. The judgment barrier, knowing what you actually need built, stayed exactly where it was. That's why the honest answer to "what if the client needs X" is no longer "there's probably a plugin for that."
There's a cost angle worth naming to the client too. An AI coding subscription runs month to month — you pay for it in the months you're actually building something and cancel the rest of the year. Compare that to a developer retainer, or a plugin license that bills you whether or not anything changed. The bill follows the work instead of taxing you for standing still.
Where this path hits its limit
Be honest about the ceiling, because you'll hit it and so will the client.
"Describe what you want" holds up right up until the request stops being a feature and starts being an architecture. What begins as "can we add a form" becomes "and can people log in," then "and can they see a dashboard of their orders," then "and can they pay through the site." Each step looks like a small addition. Collectively they're a database, an auth system, session handling, and a payment integration, which is an architectural decision the client is making without knowing they're making it.
An AI tool can probably guide a non-developer through the simplest working version of that. It can also, with total confidence, lead them down a path that works in the demo and falls over the first time two people use it at once. The failure mode isn't the tool refusing. It's the tool being sure. That's the moment to get a developer into the conversation, a 30-minute call that saves a rewrite. Not because the AI path failed, but because the question stopped being "what do you want" and became "what should this system be," and that second question still wants human judgment on the other end of the line.
Where WordPress still wins
Circle back to question one, because it's a hard line and not a hedge.
If the owner genuinely needs to run a store, gate content behind a membership, or take bookings, and operate all of it themselves with no developer in the loop, WordPress plus its library of plugins lets a non-technical person do that today. The static stack does not have a clean answer for owner-operated functionality, and pretending otherwise helps nobody.
Most small marketing sites never touch this. Some do. For those clients, WordPress is the right call, has been for twenty years, and recommending anything else because you prefer the stack is doing them a disservice. This is where WordPress belongs. No equivocation.
Setup cost: name the trade, don't hide it
The static stack is not install-and-go. It asks someone technical to model the content, wire the CMS, set up the deploy pipeline, and get preview builds and one-click rollback working before the client touches anything. That's a real day-one cost and the recommendation has to include it.
So name the trade out loud to the client: I'll spend more of your budget up front, and in exchange you won't carry a standing monthly maintenance bill. Higher cost on day one, much lower cost across every year after. Let them decide with the actual numbers in front of them instead of hiding the day-one work.
It's a gate, not a discount. If there's genuinely no one who can do that setup pass, not you and not anyone the client can reach, the recommendation doesn't hold no matter how good the rest of the math looks. No technical setup, no static stack.
What this means for the next call
The two questions still work the same way. That part didn't change.
What changed is the follow-on. A client says "but I might need X someday." That's the plugin hedge, the reason so many of us reached for WordPress by reflex, to keep the option open. The old answer was "there's probably a plugin for that." The new answer is "describe exactly what X does for your business and we'll build that, into this site, nothing else." Same client, same question, same conversation. The answer moved, and it moved on the one line that used to send the whole call back to WordPress.