Content your editors manage, in a schema your engineers define.
Payload is the headless CMS we build on when content needs to be structured, versioned and served through the same Next.js and TypeScript stack as the rest of the product.
- Payload CMS
- TypeScript
- Next.js
- PostgreSQL
- MongoDB
- S3
CMS projects often fail on the boundary between editors and engineers.
The editors get a tool that cannot express the structure the product needs; the engineers get a schema they cannot put in version control. Payload closes that gap. Collections, fields, access rules and hooks are TypeScript in the repository — reviewed, tested and deployed like the rest of the code — and the editors get an admin UI generated from exactly that schema.
It also fits the stack we already run. Payload installs inside a Next.js application, uses PostgreSQL or MongoDB underneath, and exposes both a REST and a GraphQL API plus a local API you can call from server components without a network hop. There is no separate vendor to run, no per-seat licence, and the content lives in a database you operate.
When we don’t: for a five-page marketing site that a designer will edit alone, a hosted page builder is cheaper. For enterprise digital-experience programmes with hundreds of editors, workflow approvals and multi-brand governance, we look at the larger platforms first and say so. Payload earns its place in the wide middle — products where content is data and the front end is code.
Six things we ship on Payload.
Corporate and product sites
Structured content — pages, campaigns, case studies, careers — rendered by Next.js with per-route Core Web Vitals budgets, the same discipline as our web application work.
Multi-locale content
Localised fields, fallback locales and a review flow that keeps Turkish, English and a third market in step without three copies of the site.
Editor-managed application content
The copy, tiers, FAQs and offer text inside a product — loyalty programme terms, campaign pages, help centres — edited by the business without a deploy.
Content APIs for mobile and partners
One schema, served over REST and GraphQL with field-level access control, consumed by native apps, partner portals and the web at once.
Media and document libraries
Uploads to S3-compatible storage with image variants generated on ingest, focal-point cropping, alt-text enforcement and CDN delivery.
AI-assisted editorial tooling
Hooks that draft summaries, suggest metadata or check tone against a style guide using the models from our LLM practice — with the editor approving the result.
When to choose it.
Choose Payload when your front end is or will be Next.js; when content has real structure — relationships, blocks, localisation, versions — rather than a handful of rich-text pages; when you want the schema in Git and the database under your control; and when the same content has to reach web, mobile and partners through one API. It is a strong fit for regulated industries where the location of the data is a compliance question, because Payload self-hosts cleanly on your own cloud.
Look elsewhere when the site is small enough that a hosted builder and a designer will do; when your organisation is already standardised on a SaaS headless CMS and the switching cost outweighs the licence saving; or when you need an enterprise DXP with editorial workflow, personalisation and multi-site governance at a scale Payload does not yet target. We will tell you which.
A collection definition — schema, access and hooks in one file.
export const CaseStudies: CollectionConfig = {
slug: 'insights',
versions: { drafts: true, maxPerDoc: 25 },
access: { read: publishedOrEditor, update: isEditor },
fields: [
{ name: 'title', type: 'text', required: true, localized: true },
{ name: 'industry', type: 'relationship', relationTo: 'industries' },
{ name: 'body', type: 'blocks', blocks: [Hero, Stat, Quote, RichText] },
{ name: 'seo', type: 'group', fields: seoFields },
],
// Revalidate the Next.js route the moment an editor publishes
+ hooks: { afterChange: [() => revalidatePath('/insights')] },
}Payload inside a Next.js product.
What the Payload builds we hand over have.
- Schema in version control, with generated TypeScript types consumed by the front end so a field rename fails the build rather than the page.
- Access control tested. Every collection has explicit read, create, update and delete rules, and an integration test that proves an anonymous request cannot see a draft.
- Drafts, versions and scheduled publish switched on where the business needs them — and a preview URL editors can open before anything goes live.
- Migrations, not console changes. Database migrations generated from the schema, reviewed in a pull request and applied by the pipeline.
- Media discipline: required alt text, size and format variants generated once, private buckets with signed URLs for anything not public.
- Performance budgets on the rendered site — LCP, CLS and INP per route, enforced in CI, with real-user monitoring after launch.
- Editor documentation written for editors: what each block does, where it appears, and what happens when they publish.
- Backups and restore rehearsed, because a CMS is a system of record for the words your customers read.
What usually ships alongside the code.
- Content model document: collections, globals, blocks and the relationships between them
- Payload admin configured with roles, locales, drafts and preview
- Next.js front end with generated types, ISR strategy and per-route performance budgets
- Migration scripts and a content import from the previous CMS with a reconciliation report
- CI/CD with schema checks, access tests and preview deployments per pull request
- Editor guide and a short recorded walkthrough for the content team
Frequently asked questions
Neighbouring stacks and the services that use them.
Content that needs structure, not another page builder.
Show us the content model you wish you had. An engineer reads it and replies in writing with how we would approach it.