Schema as code. Content in a separate service, in your repo.

Most headless CMS choices add a second system to the stack — separate Node service, separate database, separate access keys, separate deploy lifecycle, separate "is the staging CMS up" question on Friday afternoons. Payload collapses that. Same Node process as the application, schema declared in TypeScript and committed to git, content stored in the database the rest of the product uses. The CMS becomes part of the build, not a service that has to be reachable for the build to succeed. Running this site, we never ask "is the CMS up" — if Next.js is up, the admin UI is up. Same uptime envelope. Same observability. One thing to monitor.

Honest counter-cases. Non-technical content teams that want pure click-to-publish without engineering involvement get a sharper experience on Sanity or WordPress — Payload's admin is good but it expects editors who can navigate a TypeScript-shaped field model. Multi-tenant SaaS where each customer needs their own isolated CMS instance is a poor fit; Payload runs in your app, not as a hosted service per tenant. Marketing copy that does not justify a database — five pages of static text with occasional updates — is faster as MDX in the repo than as Payload collections. And teams without TypeScript fluency will struggle: schema-as-code is the feature, but only when the team can read the code.

After running it on this site for months, the workflow shapes that stuck:

- Collections that mirror site sections. Portfolios, services, industries, technologies, blog posts — each one its own collection definition in src/collections/, slug field drives the URL. - The seoContent mini-parser. One textarea field that recognizes ## H2, - bullet, and HTML-allowed paragraphs. Custom small parser instead of a full markdown editor — non-devs do not get distracted by formatting toolbars; devs get the structural control they want. - Idempotent seed scripts. Every new doc ships as a versioned src/scripts/seeds/<collection>/<slug>.ts file with import 'dotenv/config' at the top. Re-runnable, reviewable in PR diffs, environment-aware. Deploys are git pushes, not admin-UI clicks. - Two-database setup. A production database and a staging database, the latter auto-synced from prod every five minutes. Editing in staging is throwaway by design — production is always the source of truth. - afterChange hooks for revalidation. When a CMS doc updates, an afterChange hook fires revalidatePath on the affected route. No manual cache busts after content edits, no CDN purge dance.

For the broader engagement shape, see our web development team and custom software development approach.

Four tools we evaluate against Payload, with the actual trade-offs:

Strapi. Open-source, capable admin UI, plugin ecosystem. Trade-off: separate Node service plus separate database means twice the infrastructure surface. Our take: pick when the CMS team operates separately from the product team and they need a standalone tool — otherwise the operational tax outweighs the flexibility.

Sanity. Hosted backend with fast queries, real-time collaboration, and excellent content modeling. Trade-off: lock-in to their hosted service plus the GROQ query language. Our take: pick when content velocity matters more than infrastructure ownership and you are happy paying per seat.

Contentful. Enterprise-friendly workflows, robust roles, mature REST and GraphQL APIs. Trade-off: pricing scales steeply and the API is what you get. Our take: right for large enterprise content teams with budget and process; rarely the right call for product builds where the CMS is one component among many.

Payload. Same process as the app, schema-as-code, MongoDB or Postgres, self-hosted by default, free and open-source. Trade-off: ties content modeling to engineering ramp; non-technical teams cannot extend the schema. Our take: our default for product teams who want a CMS without operational overhead and who would rather change a schema in a pull request than file a ticket. Pairs naturally with any framework on the same Node process — we ship it with Next.js most often.