Why We Chose NextJs App Router and Payload CMS Over WordPress for Villa Sites

I get asked some version of this question fairly regularly: Why not just use WordPress? It's cheaper and everyone knows it. It's a fair question. WordPress powers a third of the internet. There are thousands of hospitality themes. The ecosystem is enormous. Here's the honest answer to why we went with Next.js App Router and Payload CMS instead — and where WordPress actually wins.

The WordPress Case (and Why It's Compelling)

WordPress has genuine advantages that I don't want to dismiss. The ecosystem is unmatched: plugins for booking engines, payment processing, calendar sync, SEO, analytics — almost anything you can think of exists and often costs less than the engineering hours to build it from scratch. Content editors are familiar with it. Developers who can maintain it are easy to hire.

For a single-property villa with modest technical requirements and an owner who wants to update their own content without learning anything new, WordPress with a good theme and a booking widget is a completely reasonable choice. I'm not going to pretend otherwise.

Where WordPress Falls Short for What We're Building

The problem with WordPress for our specific use case — a multi-tenant platform serving dozens of properties with high performance requirements — shows up in three areas: performance, scalability, and maintainability.

Performance: A carefully optimized WordPress site can perform well. But the default is poor performance, and maintaining performance under active content editing requires continuous effort. Caching plugins conflict with each other. A new plugin the operator installs breaks the optimization. With Next.js and static generation, the default is good performance, and content updates via ISR don't degrade it.

The Multi-Tenant Argument

WordPress Multisite exists and handles some multi-tenant scenarios. But it's notoriously difficult to maintain, especially across major WordPress version updates. Separate installs for each tenant is simpler but becomes operationally expensive at scale — 20 separate WordPress installs means 20 separate update cycles, 20 separate security patches, 20 separate plugin compatibility matrices.

Next.js with a single codebase and middleware-based tenant routing gives us a fundamentally different model: one codebase, one deployment, many tenants. An update to the booking flow is deployed once and works for all tenants immediately. This is architecturally cleaner and operationally much simpler at the scale we're targeting.

Why Payload CMS Over Sanity, Contentful, or Strapi

We evaluated several headless CMSes seriously. Sanity and Contentful are both excellent, but they're hosted services with pricing that scales with usage — for a platform with many tenants and lots of media, the cost curve becomes significant. Strapi is self-hosted and open source, which is attractive, but it's less TypeScript-native than we wanted.

Payload CMS is TypeScript-native, which means our data models are defined in the same language as our frontend. There's no type mismatch, no code generation step, no this type in the CMS means something slightly different from this type in the frontend. For a complex domain model — tenants, villas, rooms, availability, pricing — this type safety matters enormously for developer confidence and bug prevention.

The Honest Tradeoffs

This stack has real costs that I should be transparent about. Hiring is harder: there are far more WordPress developers than Next.js and Payload developers. The ecosystem is thinner: when we need a feature that doesn't exist, we build it rather than installing a plugin. The operational complexity is higher in some ways: we manage our own deployment pipeline, CDN configuration, and infrastructure.

These are real trade-offs. They make sense for a platform company like Moven because the investment amortizes across many tenants. They make less sense for a single property owner who wants a website and has no engineering resources. Knowing which category you're in is the most important decision in the stack selection process.

The Performance and SEO Dividend

The concrete payoff from the stack choice is visible in Lighthouse scores and Core Web Vitals. Moven-hosted properties consistently score 90–95 in Lighthouse Performance. The equivalent WordPress setup typically scores 45–65 without significant optimization effort, and drops further after a few months of content editing and plugin additions.

In 2026's SEO environment, where Google's ranking algorithm explicitly incorporates page experience signals, that 40–50 point Lighthouse difference has real ranking implications. It's not just a developer vanity metric — it translates to more organic traffic, lower bounce rates, and better conversion. That's the ultimate justification for the added architectural complexity.