Why we stopped building on WordPress
WordPress is the default answer for a lot of agencies, and it is easy to understand why. Clients recognize it, there are plugins for everything, and developers are easy to find. The problem is that those advantages come with serious tradeoffs.
Plugin conflicts, theme dependencies, database tables that were not designed for modern content structures, and a constant cycle of security patches make WordPress sites fragile over time. You end up spending time managing the platform instead of improving the site. For clients who want to grow, that is the wrong investment.
What Payload CMS is
Payload is a headless CMS built on Node.js and TypeScript. Instead of installing plugins to define your content structure, you define it in code. The admin interface is generated directly from that schema, which means clients get a clean, purpose-built dashboard that matches exactly what their site needs.
There is no plugin marketplace to navigate, no theme to fight against, and no vendor lock-in. The CMS is part of the codebase, versioned in Git, and fully owned by the client.
How it works alongside Next.js
Payload runs inside the same Next.js project as the frontend. There is no separate CMS server to deploy or maintain. The frontend and the admin panel share the same codebase, the same deployment pipeline, and the same database connection.
For clients, this means logging into a clean admin at their own domain and managing content without needing a developer. For us, it means the content model is defined in TypeScript, type-safe across the entire stack, and easy to extend when requirements change. We run all of this on infrastructure we fully control — see how we approach self-hosting and deployment for client projects.
When we use it versus Astro
Not every site needs a CMS. For landing pages, campaign pages, and informational sites that do not require ongoing content updates, we use Astro instead. Astro compiles to static HTML at build time and needs no admin interface. It is faster to build, faster to load, and simpler to maintain for that specific use case.
Payload is for everything else. When a client needs to publish content regularly, manage a team directory, update service offerings, or handle any structured data that changes over time, Payload is what we reach for. It handles the full scale of a real business website without the compromises that come with WordPress.
Email is often part of that picture too. When a Payload site needs contact forms, booking confirmations, or automated notifications, we handle delivery through Resend for transactional email — configured from day one so messages land reliably.
