Platform / Payload CMS
Payload CMS development for B2B teams that own their stack.
We build production Payload applications: TypeScript-native, self-hosted, and yours to control. No SaaS lock-in, no per-seat pricing, no waiting on a vendor's roadmap.
Request a fit checkOverview
How Payload actually works
Payload is a TypeScript-native headless CMS that you host yourself, backed by your own Postgres or MongoDB. Unlike hosted CMSes, the entire admin UI, access-control layer, and API are generated from a config you own and version in git. That makes it the strongest fit for teams that treat content infrastructure as code rather than as a rented service.
The upside is total control: custom fields, hooks, access rules, and localisation are all first-class, and there is no per-record or per-seat billing to fight as you grow. The API surface, REST, GraphQL, and a local Node API, means the same content model serves a marketing site, a mobile app, and internal tooling without a second system.
The discipline it demands is real. Payload is a framework, not a turnkey product: you own hosting, migrations, upgrades, and the data model. Done casually, that becomes a maintenance liability. Done properly, typed collections, tested access control, reproducible migrations, a considered hosting topology, it becomes the most durable content layer available to a B2B team.
We build on Payload the way it's meant to be built: as a typed, tested, self-hosted application with a deployment story that a marketing team never has to think about.
Challenges
Where Payload builds go wrong
Access control as an afterthought
Payload's field- and collection-level access rules are powerful but silent when wrong. Ship without tested access functions and you leak draft content or admin fields through the API.
Unmanaged schema migrations
Changing a collection in code without a migration strategy corrupts production data. Payload gives you migrations; skipping them is how teams lose content on deploy.
Naive hosting topology
Running the admin, the API, and the database on one under-provisioned box turns a fast CMS into a slow one. The database, media storage, and app tiers each want deliberate placement.
Rebuilding the front end inside the CMS
Payload renders the admin, not your site. Coupling presentation into the CMS instead of consuming its API from a static front end throws away the headless advantage.
What we build
Production Payload, done properly
Typed collection & field design
A content model expressed as typed config, versioned in git, that your front end consumes with full type safety.
Tested access control
Field- and collection-level access rules with coverage, so drafts and admin-only data never leak through the API.
Reproducible migrations
Every schema change ships with a migration. Deploys are safe, repeatable, and never lose content.
Deliberate hosting
App, database, and media on infrastructure sized for your traffic: self-hosted or on a managed platform you control.
Static front end on the edge
Payload feeds an Astro or Next front end pre-rendered to the edge, so content is fast and the CMS is never in the request path.
Preview & publishing workflow
Draft/publish, scheduled content, and live preview wired so your marketing team ships without a developer.
Custom admin & hooks
Bespoke fields, validation, and hooks that encode your actual editorial workflow instead of a generic one.
Upgrade & maintenance plan
A documented path for Payload version upgrades so the platform stays current without emergency rewrites.
Our approach
How we ship a Payload project
Model the content
We design the collection and field schema around how your team actually publishes, not a generic blog shape.
Build typed & tested
Collections, access control, and hooks are implemented in TypeScript with tests on the rules that matter.
Wire the front end
An Astro or Next front end consumes the Payload API and pre-renders to the edge for sub-second loads.
Ship with a runbook
Migrations, hosting, and upgrades are documented so the platform runs without us in the loop.
FAQ
Payload, questions we get asked
Is Payload a good CMS for a B2B marketing site? +
Yes, particularly for B2B teams that want to own their content infrastructure. Payload is self-hosted and TypeScript-native, so there is no per-seat or per-record billing, and the content model lives in your own git repository. Paired with a static front end on Astro or Next.js, it produces a fast, secure marketing site with a clean editing experience and no plugin ecosystem to patch.
How is Payload different from Sanity or Contentful? +
Sanity and Contentful are hosted SaaS products: you rent the backend and pay per seat, record, or API call, and your content lives on their infrastructure. Payload is a framework you host yourself, backed by your own database. That means more control and no vendor lock-in, at the cost of owning hosting and upgrades, a trade-off that favours teams treating content as code.
Do we need developers to use Payload day to day? +
No. Developers build and maintain the Payload application, but once it is live your marketing team edits content through the admin UI with no code. We wire draft/publish workflows, live preview, and scheduled publishing so content changes never require a developer or a deploy.
Can Payload handle a large, multi-language site? +
Yes. Payload has first-class localisation and handles thousands of documents comfortably on appropriately sized infrastructure. The main considerations at scale are database provisioning, media storage, and a build strategy for the static front end, all of which we design deliberately rather than leaving to defaults.
What does a Payload build cost? +
A production Payload marketing platform typically starts at £12,000 for a fixed-scope build and runs higher for complex content models, migrations, or multi-language sites. We price the scope, not the hours, so the investment is predictable before we start.
Start here
Ready to build on Payload?
A short conversation to understand your goals and determine if there's a fit. No sales pressure, no obligation.
Payload · Astro · Sanity · Next.js
Related