The question comes up in almost every discovery call where a website or web product is in scope.
"Should we use WordPress or Next.js?"
It is a reasonable question and almost always the wrong one. The real question is: what are you building, who will run it, and what does it need to do? Stack should follow use case. The technology that is right for a luxury hospitality brand's marketing site is not the same technology that is right for a multi-tenant SaaS platform. Treating these as interchangeable is how teams end up rebuilding things six months later.
This post walks through two recent WE-DO builds, what drove the stack decisions, and a practical framework for making the call on your next project.
One Stack or Two?
The tech community tends toward maximalism on this question. Either WordPress is bloated legacy software that serious teams have moved past, or Next.js is over-engineered for anything that does not require a compiler. Neither position is accurate, and both lead to bad decisions.
We have built on both stacks in the last eighteen months for real clients with real production requirements. The right answer changed based on the project, not the year or the trend cycle.
Here is what actually matters: the gap between WordPress and Next.js is not a gap in quality. It is a gap in use case fit. A site where a non-developer content team publishes daily, runs long-tail SEO at scale, and needs a mature plugin ecosystem belongs on WordPress. A product where authenticated users interact with real-time data, the UI is deeply custom, and the team ships features weekly belongs on Next.js.
When you mix those up, you pay for it.
When WordPress Wins
WordPress powers more than 43 percent of the web for a reason that has nothing to do with inertia. It is exceptionally good at a specific set of jobs.
Content-heavy sites with non-developer editors
The Gutenberg editor, custom post types, Advanced Custom Fields, and a decade of CMS ecosystem maturity mean a non-technical content team can manage a complex site without touching code. That matters enormously when you have multiple contributors, a publishing cadence, and nobody on the team who wants to push a JSON file to update a page.
For content-driven sites, the cost of requiring a developer for every content change is real. It creates bottlenecks, slows the editorial calendar, and introduces unnecessary dependency between marketing and engineering.
Long-tail SEO at scale
WordPress has a mature SEO toolset. Yoast SEO, Rank Math, and similar plugins give content teams schema markup, canonical controls, meta field management, and on-page scoring without custom development. Paired with a well-structured site and good hosting, WordPress handles the technical SEO fundamentals well.
More importantly, WordPress makes it easy to publish consistently at volume. Content velocity matters for long-tail SEO. A team that can go from brief to published post in two hours without developer involvement will out-publish a team where every deployment requires a pull request.
The Amásé Stays build
Amásé Stays is a luxury short-term rental hospitality brand offering high-end properties in the Western North Carolina mountains. The site needed to do three things well: communicate brand quality at a level that justified premium pricing, surface property listings and availability, and support ongoing content marketing for search visibility in a competitive regional hospitality market.
We built on WordPress hosted on WP Engine. See the full project in our work portfolio.
The reasons were straightforward. The editorial team needed to update property descriptions, availability notes, and blog content without developer support. The design system needed to be rich and brand-forward, which page builders like Beaver Builder handle well in a WordPress context. And the SEO requirements were content-driven, meaning long-tail regional queries where publishing velocity and on-page optimization would drive results over time.
The alternative would have been a custom Next.js build backed by a headless CMS. That would have required an additional CMS subscription, a more complex content workflow for a non-technical team, and custom development for features that WordPress plugins handle natively. The added complexity would have delivered no performance benefit that mattered for this use case.
Amásé Stays needed a platform built for content and brand. WordPress delivered that.
When Next.js Wins
Next.js is not a better WordPress. It is a different tool for a different problem.
Custom UX that does not fit a template
When the user experience needs to do something no theme or plugin covers, you are either bending WordPress in uncomfortable directions or you are building from scratch. Next.js gives you full control over the rendering layer, component architecture, and data fetching strategy. If the UI is the product, the framework that gives you complete ownership of that UI is the right choice.
Multi-tenant SaaS and authenticated applications
WordPress is built around the concept of a public-facing website with a back-end admin. It is not architected for multi-tenancy, complex authentication flows, role-based access control, or user-specific data rendering. You can bolt on some of this functionality through plugins, but the underlying data model fights you the whole time.
Next.js, paired with something like Supabase for auth and data, is purpose-built for applications where different users see different things, where sessions carry state, and where the product experience is dynamic rather than editorial.
Real-time and AI-native features
If the product needs real-time data, WebSocket connections, AI-generated responses, or streaming content, you want a framework that makes those patterns first-class. Next.js with Vercel's edge network and streaming APIs handles these use cases cleanly. WordPress requires significant custom work to get anywhere near the same result, and the result is usually fragile.
Performance-critical applications
Server-side rendering, static site generation, incremental static regeneration, and edge delivery are native to Next.js in ways that require careful configuration and plugin management in WordPress. For applications where Core Web Vitals directly affect conversion or where global performance is a product requirement, Next.js gives you more direct control over the performance stack.
The AgentPress build
AgentPress is a multi-tenant SaaS platform that gives real estate agents a personalized marketing presence and lead capture system. Each agent gets their own subdomain, customized listings page, branded content, and integrated lead forms. The platform needed to handle authentication, tenant isolation, dynamic data rendering, and a product experience that looked custom for every user.
We built on Next.js with Supabase for the database and auth layer, deployed to Vercel. Full project details in our work portfolio.
WordPress was not a serious option here. The multi-tenant architecture required row-level security in the database, user-scoped data queries, and a routing structure that depended on authenticated context. The admin experience for each agent needed to feel like a product, not a CMS back-end. And the performance requirements for a sales tool where speed directly affects lead conversion meant the rendering architecture needed to be optimized from the ground up.
AgentPress is a product. Products need a product framework.
The Decision Matrix
Before choosing a stack, answer these five questions. The pattern in your answers points clearly to the right choice.
1. Who edits the site day-to-day?
If the answer is a content team, marketing coordinator, or business owner with no developer background, that is a strong signal toward WordPress. If the answer is developers or product managers comfortable with a code-based workflow, either stack works.
2. Does the site require user authentication?
If users log in, have profiles, see personalized content, or interact with user-specific data, you are building an application. WordPress is not the right foundation for that. Next.js with a proper auth layer is.
3. How custom is the UI?
If the design can be accomplished within a well-built WordPress theme with some customization, the overhead of a custom Next.js build is hard to justify. If the design requires components that do not exist in any theme or plugin ecosystem, you need full rendering control.
4. What is the team's skill set?
A team without React or Node.js experience will be slower and more prone to errors building in Next.js. A team of JavaScript developers will find WordPress development clunky and slow. Honest assessment here matters more than what sounds impressive on a roadmap.
5. How often do you ship features?
For a marketing site, quarterly content updates and annual design refreshes might be the entire maintenance cadence. For a SaaS product, you might ship multiple times per week. Deployment velocity requirements should influence the tooling choice significantly.
The Hybrid Case
Sometimes the answer is both.
A common and genuinely effective pattern is running a WordPress marketing site alongside a Next.js application. The marketing site handles content, SEO, and brand. The application handles the product experience. They share a domain through subdomain routing or a reverse proxy.
This pattern shows up frequently in SaaS companies. The www or /blog property runs on WordPress because the growth team can execute a content strategy without engineering support. The app. subdomain runs on Next.js because the product team needs full control. The two stacks serve different audiences with different needs and never get in each other's way.
The hybrid approach does add operational complexity. You are managing two deployment environments, two codebases, and two sets of dependencies. For a company with a small technical team and no clear separation between marketing and product, that overhead might not be worth it. For a company at the stage where marketing and product genuinely have different paces and requirements, the separation pays dividends.
Common Stack Mistakes
Getting this decision wrong is expensive. Here are the patterns we see most often.
Using Next.js for a brochure site. A five-page website for a service business does not need a custom React application. The build time, hosting configuration, and ongoing maintenance burden are not justified when a well-built WordPress theme would have been live in a fraction of the time and cost. The team that chose Next.js will spend the next year fighting "just change the phone number" requests that require a deployment.
Using WordPress for a real-time application. The inverse problem. A startup that tries to bolt authentication, real-time data, and SaaS-style UX onto WordPress will accumulate technical debt at an alarming rate. Custom plugin conflicts, plugin update breakage, and a data model that was never designed for application-level complexity create compounding maintenance burdens.
Resume-driven development. The most common failure mode of all. Someone on the team wants to learn a new framework, or a developer wants to add something to their portfolio, and the technology choice reflects that ambition rather than the project's actual requirements. This is how a regional restaurant group ends up with a custom Next.js site that nobody on staff can update, and how a SaaS startup ends up with a WordPress back-end that cannot support their product roadmap. Make the technology decision based on what the product needs, not what the team wants to work on.
A Recommendation Framework
If you leave this post with one thing, it should be this: the stack follows the use case, not the other way around.
Start from what the site or product actually needs to do. Map that to the signals in the decision matrix above. If the signals are mixed, ask which requirements are non-negotiable. Authentication requirements are non-negotiable. Content team editability requirements are non-negotiable. Those hard constraints usually resolve the ambiguity.
When in doubt, consider scope. WordPress is the right default for marketing sites, content hubs, and brand properties where the primary job is publishing and SEO. Next.js is the right default for applications where the primary job is delivering a custom, authenticated, or performance-critical product experience.
The technology that is harder to implement is not automatically the better choice. The right choice is the one that fits the work in front of you, the team behind it, and the users who will depend on it.
If you are working through a stack decision for an upcoming build and want a second opinion, reach out to WE-DO. We have made this call enough times to know where the traps are.
WE-DO is a growth marketing agency that builds and grows web properties for founders and operators. Our work spans WordPress, Next.js, and everything in between.
