For a decade I built everything in WordPress. Client site? WordPress. Personal blog? WordPress. Marketing microsite? WordPress. It was the default, and defaults are fast.
Now I reach for Astro, Next.js, or Webflow first. I still use WordPress — more often than the 'WordPress is dead' crowd would like — but only when the requirements actually demand it. Here's the decision framework that changed my mind, and a specific case where WordPress was the right call (even though almost everyone assumed it wasn't).
Three questions I ask before picking WordPress
1. Is the editor non-technical, high-frequency, and resistant to learning new tools?
WordPress's Gutenberg editor has problems but it's unmatched for 'my marketing assistant who publishes three posts a week and expects it to just work.' Every alternative CMS requires training and ongoing discipline. If the editor won't invest 30 minutes to learn a new tool, WordPress wins on operational cost alone.
2. Do I need a specific plugin ecosystem that doesn't exist elsewhere?
Paid Memberships Pro, WooCommerce, LearnDash, The Events Calendar, WP-CLI — these are mature plugin ecosystems with thousands of integrations, and they don't have direct equivalents on other stacks. If the project needs any of them, WordPress isn't 'easier,' it's the only option that doesn't require custom development.
3. Will this site need to survive 5+ years with minimal developer involvement?
WordPress's downside is maintenance burden. Its upside is plugin longevity. If a project is going to sit without a developer on retainer, WordPress's ability to auto-update itself (however imperfectly) beats any custom stack that relies on a specific developer knowing how to redeploy.
If the answer to any of these is 'yes,' WordPress is still the right call. If all three are 'no,' the modern stack almost always wins.
Where WordPress loses
- Performance budgets. A default WordPress install loads 15+ stylesheets, 10+ scripts, and a PHP render cycle per request. Page Speed is fixable with caching — but you're always paying the cost of a system that wasn't built for performance-first delivery.
- Edge deployment. WordPress runs on PHP servers. You can CDN the output, but the origin is a persistent VM or managed host with a minimum monthly cost. Astro's static output runs on Cloudflare Pages for cents. For marketing sites with predictable traffic, the cost delta is 10 to 100x.
- Design fidelity. Elementor, Bricks, and the like are closer than they used to be, but if the design is pixel-specific or has unusual interactions, the friction of matching a designer's vision in a visual builder is higher than just building it in React. Once you're in a custom theme, WordPress's advantages largely evaporate.
- Multi-channel content. If the content needs to feed a mobile app, a newsletter system, and a public site simultaneously, WordPress's template-coupled content model fights you. A headless CMS (Sanity, Contentful) handles this natively. I wrote about the content model tradeoffs in CMS Architecture for Multi-Language Enterprises.
The decision matrix
Here's the quick cut I actually use, comparing WordPress, Astro/Next, and Webflow:
- Non-technical daily editor: WordPress wins, Webflow ties, Astro+Sanity loses (needs training).
- Performance (sub-1s LCP): Astro wins cleanly, Webflow close second, WordPress needs work.
- Design fidelity: Astro and Webflow win, WordPress themes usually compromise.
- E-commerce 100+ products: WordPress with WooCommerce wins, everything else is custom.
- Memberships and paywalls: WordPress with PMPro wins; custom-built elsewhere.
- Monthly hosting cost: Astro $0-20, WordPress $15-200, Webflow $25-200.
- 5-year maintenance burden: WordPress wins (auto-updates), Webflow ties (managed), Astro needs a dev.
The matrix isn't a decision tool — it's a conversation starter. But if you're defaulting to WordPress without looking at this grid, you're probably over-serving the project.
The case where WordPress was right
The project that forced me to articulate this framework was Flow in Faith. The site started on a custom Next.js stack with Clerk for authentication and a custom Stripe integration for memberships. By every 'modern stack' metric, it was the right answer: performant, edge-deployed, designer-friendly.
It was also a nightmare to maintain. The custom Stripe integration was 2,300 lines of plugin code. Every auth change required a developer. The membership system couldn't be updated without a code deploy. The client had hired me to reduce their dev dependency, and I was making it worse.
The rebuild took the opposite bet: migrate to WordPress with Paid Memberships Pro. I rewrote the 2,300 lines of custom code into PMPro-compatible hooks, styled all 12 PMPro pages (login, registration, checkout, account, confirmation) to match the Flow in Faith brand, and built Elementor templates for consistent page design.
The outcome: the client can now update pricing, add member benefits, manage churn, and issue refunds without calling a developer. The site is slightly slower than the Next.js version. The monthly hosting cost is $15 higher. Both trades were worth it because the operational independence is what the client actually needed.
This is the architect mindset: the best stack isn't the one that wins on benchmarks, it's the one that solves the operational problem. For the opposite call — when a modern stack was the right bet on a similar budget — see Building an Awards Platform from Zero: Pulse Awards Architecture.
The takeaway
Stack snobbery is a junior developer's disease. The mid-career version is 'modern stack by default.' The senior version is 'the right stack for this specific project, explained on one page.' If you're picking a stack for your next project — for yourself or a client — run it through the three questions above before defaulting to whatever you used last time.
If you want a second set of eyes on a stack decision in progress, that's what the Architecture Review package is for. One week, a written decision record, no hype.