WordPress or React? How we choose a stack for a client site
We ship client work on both, so we have no horse in this race. The honest answer to "which is better" is a short set of questions about your team, your content, and what the site has to do.
May 12, 2026
2 minutes
Start with who edits the site
The first question is not technical: who touches this site after launch, and how often? When a client team publishes news, manages documents, and runs an annual content cycle themselves — the way the RU Foundation team maintains board listings, 990s, and reports — WordPress earns its keep. The editing experience is the product for that team, and a mature CMS gives it to them without a developer in the loop.
If the answer is "the content changes twice a year and marketing sends us the copy," a CMS is overhead wearing a feature costume.
Then ask what the site has to do
The more the site behaves like a product — filtering, comparison, dashboards, anything with application state — the harder we lean toward React. A health plan shopping engine like Peekaboo or a platform like Qentoros is an application that happens to live at a URL; building that as a pile of plugins is how WordPress projects go sideways.
Brochure and content sites sit at the other end. When the job is communicating clearly, loading fast, and being easy to maintain, both stacks can do it well, and the deciding vote goes back to who edits the site.
The costs nobody puts in the proposal
WordPress carries an ownership cost: core and plugin updates, hosting hygiene, and the discipline to keep the plugin count low. A neglected WordPress site does not stay neutral — it decays. React carries a different one: without a CMS attached, every content change is a code change, which means either a developer relationship or a headless CMS and the complexity that adds.
Neither cost is a dealbreaker. Both are real, and a proposal that mentions neither is not being straight with you.
How the decision actually falls
In practice: frequent self-service publishing by a non-technical team points to WordPress. Product-like behavior, custom interfaces, or an app roadmap points to React. Either way, the constants do not change — semantic, accessible markup, per-page metadata, fast loads, and a build the client can actually live with for five years. The stack is a tool. The standards are the point.