Why we bet on Next.js and Payload

Choosing a stack is choosing a set of constraints you will live with for years. For content-driven products we keep landing on the same pairing: Next.js on the front, Payload as the CMS, Postgres underneath.

This site runs on it, so the opinions below are operational rather than theoretical.

What Next.js is actually for

The useful part is not the framework's popularity. It is being able to choose a rendering strategy per route rather than for the whole site.

• Static for pages that rarely change — fast, cacheable, cheap.
• Server-rendered for pages that must reflect the database immediately.
• Client-side only where genuinely interactive, which on a marketing site is almost nowhere.

Most sites do not need that flexibility. The ones that mix marketing pages, a content-managed blog and a genuine application behind a login very much do, and that combination is exactly where alternatives start to strain.

Why Payload rather than a hosted CMS

Hosted CMS platforms are good and we use them where they fit. The reasons we usually do not:

• Your content lives in someone else's database, priced per seat and per API call.
• The content model is constrained by what the platform can express.
• There are two systems to deploy, keep in sync and debug when they disagree.

Payload runs inside the same application and stores content in your own Postgres. One codebase, one deploy, no sync layer. Editors get a real admin interface; you keep the data.

The honest trade-offs

It is not free. The costs, plainly:

• You run the database. That is an operational responsibility a hosted CMS removes entirely.
• Self-hosting means patching, backups and monitoring are yours.
• The ecosystem is smaller than WordPress by orders of magnitude, so fewer off-the-shelf plugins exist.
• Next.js moves quickly, and major versions have required real migration work.

Anyone presenting a stack choice as having no downsides is selling rather than advising.

When we would not use it

A simple brochure site with three pages and no application behind it does not need any of this. Squarespace or a good WordPress theme will be live sooner, cost less and be perfectly adequate — and we will say so rather than quoting a build.

The pairing earns its place when the site is a front end onto something: a product, a portal, a catalogue, an academy. On this site the same deployment serves the marketing pages, the CMS, the free tools and a student portal with its own auth. Splitting that across three platforms would be the expensive option, not the cheap one.

What it costs to run

Hosting is modest. The real ongoing cost is dependency upkeep — security patches, framework upgrades and the occasional breaking change. Our note on what software costs after launch covers how to budget that honestly.

For what building on this stack looks like as a number, see our website cost breakdown.

When is Next.js and Payload the wrong choice?

For a simple brochure site with three pages and no application behind it. Squarespace or a good WordPress theme will be live sooner, cost less and be perfectly adequate. The pairing earns its place when the site is a front end onto something — a product, a portal, a catalogue, an academy — where the alternative is running three separate platforms.

What does self-hosting Payload actually cost you?

You run the database, which a hosted CMS removes entirely, and that means patching, backups and monitoring are yours. The ecosystem is also far smaller than WordPress, so fewer off-the-shelf plugins exist. In exchange your content lives in your own Postgres rather than someone else's database priced per seat and per API call.