Building with Next.js and Payload CMS

When we built nestech.co.nz, we treated it as a real project — the same discipline, the same stack choices, the same process we'd apply to a client engagement. That meant being deliberate about technology selection rather than defaulting to whatever was familiar. We landed on Next.js 15 with Payload CMS v3, and it's worth explaining why, because the reasoning applies to a lot of what we recommend to clients.

Next.js has become the dominant framework for serious React applications, and version 15 makes a compelling case for why. Server components are the significant shift: they let you render on the server where it makes sense — data fetching, heavy computation, content that doesn't need to be interactive — while keeping client-side interactivity where it actually adds value. The result is faster initial page loads, better SEO, and applications that feel responsive because they're not shipping unnecessary JavaScript to the browser.

The deployment story with Next.js is also strong. Edge deployment means your application runs close to your users geographically, reducing latency. Static generation handles pages that don't change frequently — most of a content-heavy site — and serves them at CDN speed. Dynamic rendering handles the parts that need to be current. You get to make that choice per-page, per-component, which means you're not stuck with a one-size-fits-all approach.

Payload CMS v3 is what makes the content management side of this stack genuinely interesting. The key architectural decision: Payload runs inside your Next.js application. There's no separate CMS server to maintain, no separate hosting cost, no integration layer to keep synchronised. Your content model is defined in TypeScript, which means your editor, your compiler, and your runtime all understand the shape of your data. If you change a field in your content model, TypeScript tells you everywhere in your codebase that needs to be updated before you ship.

The contrast with WordPress is stark. WordPress is ubiquitous for a reason — it's accessible, there's a huge ecosystem, and it works for a lot of use cases. But it carries significant maintenance overhead, security patching is a constant concern, and the developer experience for building custom functionality has not kept pace with modern tooling. Contentful and Strapi are better fits for developer-centric projects, but both introduce vendor dependencies and integration complexity that Payload sidesteps. With Payload, your content model is code, it lives in your repository, and you control it entirely.

Content workflows were a specific requirement for us. The Nestech site runs a draft/review/publish cycle where nothing goes live without explicit approval. Payload's access control and version management make this straightforward to implement. Authors can create and edit content in draft state, reviewers can check and approve, and publishing is a deliberate action rather than an accidental one. For a professional services business where what goes on your website reflects directly on your credibility, that kind of control matters.

The AI integration angle is relevant here too. A code-first, API-native CMS with well-typed data structures is the kind of system AI tools can actually work with effectively. Content can be structured so that AI-assisted drafting, summarisation, or translation plugs in naturally. We're already using AI in our content pipeline — not to replace editorial judgment, but to handle the tedious parts: generating initial drafts from briefs, suggesting metadata, flagging inconsistencies in tone. The stack makes this integration natural rather than bolted-on.

Performance results have been what we expected from the architecture. Build times are fast. Pages that can be statically generated are served at CDN edge with sub-100ms response times. Dynamic pages — search results, filtered views — are handled by server-side rendering with appropriate caching. The Lighthouse scores are strong across the board, which matters both for user experience and for search visibility. We didn't have to do anything exotic to achieve this; it's what you get when the framework is designed with performance as a first-class concern.

The broader point is about choosing tools that will still be appropriate choices in three to five years. WordPress has been around since 2003 and will be around in 2030. But the web has moved on significantly, and the gap between what modern frameworks offer and what legacy CMS platforms can match continues to widen. Next.js and Payload represent where serious web development is heading: type-safe, API-first, AI-ready, built for performance at the edge. We use this stack on our own site because we'd recommend it to clients, and we recommend it to clients because we've validated it on our own site.

If you're building something new — a platform, a client portal, a content-heavy site that needs to be maintainable by non-developers — it's worth talking to us about whether this stack fits your context. We're not dogmatic about it; the right tool depends on the problem. But for a wide range of modern web projects, Next.js and Payload is the combination we keep coming back to, and now you know why.