Payload CMS Development

We design and build production Payload CMS systems: content modelling, a custom admin your editors can actually use, and the infrastructure to run it. Headless, TypeScript-first, API-driven.

Built for performance and control: Next.js, TypeScript, Payload CMS, Medusa.js, Stripe, Vercel. We ship fast with clean code, strict security, and measurable outcomes.

Outcome‑first

Security‑minded

Performance‑driven

Payload technology stack

CMS and commerce

Runtime and language

Database

Cloud and deployment

Comprehensive Payload CMS Development Services

A production‑ready Payload stack: strong content model, clean APIs, and a delightful authoring experience.

Implementation & Setup

Project scaffolding, Payload config, authentication, access control and media storage, set up so the project is deployable from week one rather than at the end. Media storage in particular is configured before launch, not after: on some hosts, files written to local disk disappear on every redeploy, silently.

Content Modeling

Collections, globals and the relationships between them, shaped around how the business actually works rather than around what is quick to configure. This is the part that decides whether the system is still pleasant to use in year three.

Custom Admin UI

Fields, validation rules and editor workflows built so a content team can work without a developer beside them. Payload allows deep customisation of the admin panel, and most projects under-use it. Editors pay for that daily.

API & Integrations

REST and GraphQL out of the box. The work is in what you connect them to: commerce backends, search, payments, analytics, internal systems. A frequent pairing is Medusa.js for commerce alongside Payload for content.

Ecommerce & Catalog

Product content, merchandising blocks, pricing tables and multi-locale catalogues: the editorial layer that sits alongside a commerce engine rather than trying to replace it. See running content and commerce together.

Security & Governance

Field-level access rules, roles, audit trails, backup strategy and deployment practice. Payload access control is granular enough for B2B portals and multi-team editorial operations, where “who can change what” is a real requirement.

Why choose Payload CMS

TypeScript-first

Strong typing across schemas, hooks and access control, so fewer runtime surprises.

Self-hosted, on infrastructure you own

Payload is MIT-licensed and runs on your own infrastructure. Since Payload Cloud paused new sign-ups following the Figma acquisition, new projects self-host, which is why we treat hosting and its running cost as part of the build.

Powerful access control

Granular, field-level rules. Suited to B2B portals and editorial workflows.

One deployment, not two

Since v3, Payload runs inside your Next.js application. The admin panel, the APIs and the frontend are one codebase and one deploy. No separate CMS server, no CORS layer between them.

Where Payload fits

Platform

How it's built

Fits when

Payload

Runs inside your Next.js app: one deployment, full TypeScript types from schema to frontend, code-defined content model

Your team lives in Next.js, you want type safety end to end, and you are comfortable owning infrastructure

Strapi

A separate API server with a visual content-type builder and a larger plugin marketplace

You want the CMS independent of any one frontend, or need non-developers building content models

Sanity

Hosted content platform with real-time collaborative editing

Content-heavy publishing where several editors work the same document simultaneously

Payload with Medusa

Medusa holds the commercial truth: products, variants, prices, inventory, orders. Payload holds the editorial truth: long-form product stories, buying guides, campaign pages, media, translated copy.

The two are joined at the point a customer sees a product page. Medusa publishes an official integration pattern for this, and the important detail is that it links the two systems with a pointer rather than a copy.

A virtual link connects a Payload record to a Medusa product, so a single query returns both and there is no duplicated product data to drift out of sync. Events in Medusa create the matching content record in Payload automatically.

The rule that keeps it stable: every field has exactly one owner, and data flows one direction. Price lives in Medusa and is never copied. Editorial content lives in Payload and never flows back. Read more in Payload CMS and Medusa or see our Medusa.js development services.

What it costs to run

Payload is MIT-licensed, so there is no licence fee and no per-editor seat. That is not the same as free, and it is the question we are asked most.

A production Payload deployment needs four things beyond the application: a database (Postgres or MongoDB, there is no production-grade file-based option), object storage for uploaded media, an email provider for password resets and notifications, and a CDN. Plus the part that appears on no pricing page: somebody who patches, upgrades, restores backups and answers when it breaks. That operational ownership is usually the larger cost.

Rough infrastructure bands, before that human cost:

Marketing or small content site

~$25 to $60 a month. One environment plus light staging, modest media.

Business site or commerce frontend

~$80 to $250 a month. Real staging, several editors, a meaningful media library, a managed database with backups.

Multi-market or media-heavy

$300 a month and up. Multiple locales, a large image library, traffic spikes, where the variable is bandwidth rather than compute.

Media storage is where this goes wrong

Some hosts wipe uploaded files on every redeploy, with no error. Worth settling before anyone commits to a host.

Egress, not storage

For an image-heavy site, moving files is usually the largest line on the invoice, ahead of storing them.

Accounts in your name

We set the infrastructure up on whichever provider fits: Vercel, Railway, Hetzner, AWS. In accounts held in your name, so the bill comes from the provider rather than through us. More detail in Payload CMS hosting and cost in production.

How we build

1/7

Performed by senior business analysts, technical architects and domain experts.

Requirement analysis

2/7

High-level and low-level design developed from the SRS document.

Software architecture

3/7

UX research, then UI and UX design.

Design

4/7

Driven by Agile, DevOps and CI/CD.

Coding

5/7

Continuous testing, the dev team fixing issues, the QA team rechecking functionality.

Quality assurance

6/7

Final deployment launched, with the QA team checking the software on the production environment.

Deployment

7/7

Bug fixing, software upgrades and enhancement with new features.

Maintenance

Habitat: an editorial shopping build

A reference implementation we built on Payload CMS v3 and Next.js 16: an editorial commerce experience where a reader browses styled room scenes, taps a hotspot on the image to see the product, and adds it to a cart without leaving the article. This is our own build rather than a client project, published so you can read how the capability works instead of taking our word for it.

Stack

Payload CMS v3, Next.js 16, TypeScript, Tailwind, Lexical

Project type

Our own reference build, not a client project

Content model

Six collections, a homepage global, nine custom block types

Environments

SQLite and local files in development, Postgres and object storage in production

What was built

Visual hotspot editor

A custom Payload admin component. An editor clicks directly on the image to place a hotspot and picks the product from a grid, with no coordinates typed by hand.

Live preview with breakpoints

An editor sees the real rendered page at each device width before publishing.

Nine custom block types

Shoppable scenes, product cards, styling tips, material callouts, pull quotes, image pairs and budget breakdowns, composed by editors rather than hard-coded.

Environment-adaptive infrastructure

SQLite and the local filesystem in development, Postgres and object storage in production, detected automatically with no code change between the two.

Frequently asked questions

The open source project continues under Figma backing and remains MIT-licensed. What changed is hosting: new Payload Cloud sign-ups are paused, so new projects self-host. Existing Cloud projects continue running.

They are built around different assumptions. Payload runs inside your Next.js application as one deployment with full type safety. Strapi runs as a separate API server with a larger plugin marketplace and a visual content-type builder that non-developers can use.

Yes, if the admin is built for them rather than left at defaults. That is a build decision, not a platform limitation, and it is where we spend real design effort.

Only if you are selling. Payload alone covers content sites, marketing sites and applications. The pairing matters when product data and editorial content both need a proper home.

Infrastructure typically runs from around $25 a month for a small content site to $300 and up for multi-market, media-heavy builds. The larger cost is operational ownership.