WordPress powers roughly 40% of the web. It's the default recommendation from most agencies, most freelancers, and most "how to start a business" blog posts. It's also the single most common technical debt we inherit when clients come to us for a rebuild.
We don't use WordPress at Aetheris. Not because it's bad software -- it's genuinely impressive for what it was designed to do. We don't use it because the projects we build have outgrown what it was designed for, and forcing WordPress into those shapes creates problems that cost more to fix than building right from the start.
The five limitations that matter
1. Plugin dependency is a structural risk
A typical WordPress site runs 15 to 30 plugins. Each one is a separate codebase maintained by a separate developer or team, with its own update schedule, its own security posture, and its own compatibility constraints. When Plugin A updates and breaks Plugin B, you're debugging someone else's code -- or waiting for someone else to fix it.
We've inherited WordPress sites where updating a single plugin cascaded into three days of compatibility fixes. That's not an edge case. That's Tuesday.
2. The security surface area is enormous
WordPress is the most targeted CMS on the internet. Not because it's insecure by design, but because its ubiquity makes it the highest-value target. Every plugin is a potential attack vector. Every theme is a potential attack vector. The admin panel sits at a predictable URL. Brute force attacks against /wp-admin are so common that security plugins to block them are themselves a multi-million dollar industry.
For a simple blog, this risk is manageable. For a platform handling user data, payments, or sensitive business logic, it's a liability we're not willing to accept on behalf of our clients.
3. Real-time features don't fit the model
WordPress was built for content that gets published and then read. Request comes in, server renders the page, sends it back. That model breaks the moment you need live data -- real-time scores for BookIt Sports, live content feeds for Footy Access, instant notifications for Edge Athlete OS.
You can bolt real-time onto WordPress with plugins and custom PHP, but you're fighting the architecture instead of working with it. Every real-time feature becomes a special case instead of a natural part of the stack.
4. Performance requires constant management
Out of the box, WordPress is not fast. Making it fast requires caching plugins, image optimization plugins, CDN configuration, database optimization, and ongoing monitoring. A well-tuned WordPress site can be quick. But "well-tuned" means someone is actively managing performance -- and the moment a new plugin or theme update ships, the tuning may need to be redone.
Compare that to a Next.js site on Vercel. Static pages are pre-rendered at build time. Dynamic pages use server components that stream HTML directly. Images are automatically optimized. The CDN is built in. There's no caching layer to configure because the architecture doesn't need one for most use cases. Our clients' sites consistently score 95+ on Lighthouse without any performance-specific work.
5. The scaling ceiling is real
WordPress can handle significant traffic with proper infrastructure. But "proper infrastructure" for WordPress means managed hosting, load balancers, database replicas, and object caching -- all of which add operational complexity and cost.
A Next.js application on Vercel scales to zero when there's no traffic (you pay nothing) and handles traffic spikes automatically through edge functions and CDN distribution. When Odunde's festival platform needed to handle event-day traffic surges, we didn't think about scaling for a single second. The infrastructure handled it.
When WordPress IS the right call
We're opinionated, not dogmatic. WordPress is genuinely the best choice in specific situations:
-
Pure content sites with non-technical editors. If the entire site is blog posts and pages, and the people updating it aren't comfortable with anything more technical than a rich text editor, WordPress's admin UI is hard to beat. It's mature, intuitive, and well-documented.
-
Tight budgets with simple needs. A small business that needs a five-page website with a contact form can get a WordPress site up for a few hundred dollars. That's a legitimate value proposition we won't pretend doesn't exist.
-
Existing WordPress ecosystems. If a client has 500 blog posts, a trained editorial team, and workflows built around WordPress -- migrating for the sake of migrating is wasteful. We'll build new features alongside WordPress rather than force an unnecessary rewrite.
We've turned down projects where WordPress was clearly the right tool. Taking a client's money to over-engineer a solution they don't need isn't how we build long-term relationships.
What we use instead
Our standard web stack is Next.js with TypeScript, Tailwind CSS, and Vercel. For projects that need content management, we pair that with a headless CMS -- typically Sanity or Contentful, depending on the client's editorial needs.
Here's what that architecture looks like in practice:
The frontend is a Next.js application. Server components handle data fetching and rendering. Client components handle interactivity. Everything is type-safe, everything is fast, and the developer experience means we ship features quicker.
The CMS is headless -- it manages content through its own interface but doesn't control how that content is displayed. Content editors get a clean, purpose-built editing experience. Developers get structured data through an API. Neither side is constrained by the other.
The deployment is Vercel. Git push triggers a build. Preview deployments for every branch. Production deploys with instant rollback. Zero server management.
This stack powers every web project we've shipped in the past year. WSV, BookIt Sports, Footy Access, NXTGEN Media -- all built on the same foundation, all performing at a level that WordPress would require significant effort to match.
The performance gap in practice
Here are real numbers from projects we've built:
- WSV (Next.js): Lighthouse performance score of 97. Time to first byte under 100ms. Total page weight under 500KB.
- Footy Access (Next.js): Content pages load in under 1.5 seconds on 3G connections. Zero caching configuration required.
- A WordPress site we migrated from: Lighthouse score of 62 with three caching plugins active. Time to first byte of 800ms. Total page weight over 3MB due to plugin-injected scripts.
The difference isn't subtle. Users feel it. Google measures it. Conversion rates reflect it.
Migration is less painful than you think
We've migrated clients off WordPress multiple times. The process is straightforward:
- Content export. WordPress has solid export tools. Blog posts, pages, media -- all extractable as structured data.
- Design rebuild. We rebuild the frontend in Next.js, typically improving the design in the process. This is the bulk of the work.
- CMS setup. Content gets imported into the headless CMS. Editors learn the new interface (usually in a single training session).
- Redirect mapping. Every old URL gets a redirect to the new URL. No SEO value is lost.
The typical migration takes two to four weeks depending on content volume. Clients consistently tell us the new editing experience is better, the site is faster, and they spend less time fighting their own tools.
The bottom line
WordPress is a good tool that gets used for things it wasn't built for. We don't use it because the platforms we build -- real-time sports applications, media networks, coaching tools, festival platforms -- need an architecture that treats performance, security, and scalability as defaults rather than afterthoughts.
If your needs are simple, WordPress might be perfect. If you're building something that needs to grow, we'd rather start with a foundation that grows with you.