Development

Next.js + Payload CMS for SaaS: When This Stack Is the Right Choice

Rupam ·

The Next.js + Payload CMS combination has become a default for SaaS teams that want a typed, code-first CMS without giving up React’s frontend ecosystem. Payload 3 (released late 2024) merges directly into a Next.js app — same codebase, same deployment, same authentication model. For SaaS where the marketing site, app, and CMS need to share a frontend stack, this combination is currently among the strongest options.

Key takeaways

  • Payload 3 is genuinely a Next.js-native CMS. It runs as a Next.js route (/admin) inside your existing app rather than as a separate service. One deployment, one auth system.
  • The schema-first approach scales well. Payload collections defined as TypeScript code give you typed queries, generated GraphQL/REST APIs, and an auto-generated admin UI. The CMS adapts to your data model, not the reverse.
  • The trade-off is operational, not technical. Self-hosted by default. You’re responsible for the database (MongoDB or Postgres), the file storage, the upgrade cycle. WordPress’s hosted-CMS muscle memory doesn’t apply.
  • It’s not a Sanity or Contentful replacement for everyone. If you don’t have engineering capacity to maintain a self-hosted CMS, hosted alternatives are simpler.

What Payload 3 actually is

Payload is a TypeScript-first headless CMS. You define collections (content types) as TypeScript code; Payload generates the database schema, the admin UI, and the API. Both REST and GraphQL APIs are auto-generated; access control, hooks, custom fields, and relationships are all defined in code rather than clicked through a UI.

Payload 3’s significant change: it now runs as a Next.js route handler. You don’t deploy a separate Payload service — you add Payload to your Next.js app, mount it at /admin, and ship one application. The CMS and the frontend share the same Next.js runtime, the same database connection, the same auth.

Why this fits SaaS specifically

SaaS products typically have three frontend surfaces: marketing site (homepage, pricing, blog), authenticated app (dashboard, settings), and admin (content management, support tools). With a separate headless CMS:

  • Marketing site is a Next.js app fetching from the CMS
  • App is another Next.js app fetching from the application database
  • CMS is a third service (Sanity, Contentful, Strapi)
  • Admin tools are a fourth thing (often custom-built Retool/Forest)

Three to four moving pieces, three to four deployments, three to four auth integrations. Payload + Next.js collapses this into one app: marketing pages and CMS admin both live in the Next.js project; the application database can be the same Postgres instance Payload uses; admin tools can be built into Payload’s admin UI as custom components.

The architecture pattern

  • Single Next.js app with App Router
  • Payload mounted at /admin for the CMS interface and editorial workflows
  • Marketing pages as Next.js App Router routes consuming Payload’s local API at build time or via SSR
  • Authenticated app routes sharing the auth system with Payload
  • Postgres database serving both Payload’s collections and the application’s user data
  • S3-compatible storage (Cloudflare R2, AWS S3, Backblaze B2) for media uploads
  • Single deployment to Vercel, Railway, Fly.io, or your own infrastructure

Where this gets complicated

  • Vercel hosting limits. Vercel’s serverless functions have time limits (10–60 seconds depending on plan). Long-running Payload operations (large media uploads, bulk imports) can hit these. Workarounds: route long operations via background jobs (Inngest, Trigger.dev) or self-host on Railway/Fly for unrestricted execution time.
  • Database choice trade-offs. MongoDB (Payload’s original support) is simpler for nested document data; Postgres (now first-class) is more familiar and easier to share with the application. Both work; pick based on team familiarity.
  • Migration tooling. Payload’s migrations are functional but less mature than Prisma’s. For applications with significant schema evolution, expect to write migration code yourself.
  • Plugin ecosystem. Smaller than WordPress; growing but you’ll occasionally write integrations yourself that would have been a plugin install in WordPress.

Comparing to alternatives

  • vs Sanity / Contentful: Payload is self-hosted; they’re SaaS. Payload’s TypeScript-first model is more familiar for engineering teams; Sanity’s GROQ query language is unique to Sanity. Cost: Payload is free + your hosting; Sanity/Contentful charge per content entry and API call.
  • vs Strapi: Both are self-hosted, code-first CMSes. Payload’s TypeScript-first ergonomics and Next.js integration are stronger; Strapi’s plugin ecosystem and admin UI are more mature.
  • vs WordPress headless: WordPress has a dramatically larger plugin ecosystem and editor familiarity. Payload has cleaner architecture, better TypeScript integration, and smaller operational footprint. Different fits for different teams.
  • vs Prisma + custom admin: Prisma + a custom-built admin gives you maximum flexibility but enormous engineering investment. Payload gives you the admin UI for free.

FAQ

Is Payload production-ready for serious SaaS?

Yes. Payload 3 is stable; companies are running production workloads on it. The framework is past early-adopter status.

Can I use Payload as just the CMS without coupling to my app?

Yes. Payload runs as a standalone Next.js project too, exposed via REST/GraphQL APIs. The fully-merged-with-the-app pattern is one option; running Payload as a separate CMS service is also fully supported.

What about real-time collaboration?

Payload’s admin doesn’t have real-time collaborative editing like Notion or Google Docs. For most CMS workflows this isn’t a problem; for high-volume editorial teams it can be. Optimistic locking and revision history are supported.

Should I migrate from WordPress to Payload?

Only if you have a specific engineering reason. WordPress’s editorial UX, plugin ecosystem, and editor familiarity are real strengths. Payload makes sense when your team is engineering-heavy, you want a unified codebase, and you’re comfortable taking on the operational responsibility.

What’s the realistic timeline for a Next.js + Payload SaaS build?

For a typical SaaS with marketing site, authenticated app, and Payload-driven content management: 6–12 weeks for an MVP. Faster if you start from a starter template (Payload has good ones); slower if you’re integrating with existing infrastructure.

Want help with a Payload + Next.js build?

EtherLabz builds and consults on Payload-based architectures. Book a discovery call.

Written by Shadow, with input from the EtherLabz team.