Building Applications with Payload CMS Instead of a Custom Admin Panel

The Problem #

Team Enoch needed to edit their own service pages, pricing sections and service-area copy without filing a ticket for every change. A hand-rolled admin CRUD screen for each content type was the obvious first instinct, and also the wrong one at this scale — five content types meant five sets of forms, validation and permissions to build and maintain.

Context #

This was a marketing site on Next.js where the actual frontend needs were straightforward; the real complexity was entirely on the "how does a non-developer edit this safely" side.

What I Tried #

Started building a bespoke admin route with its own forms for the first content type (service pages), planning to repeat the pattern for the rest.

What Went Wrong #

Each new content type meant re-deriving the same problems: field validation, image uploads, draft vs. published states, and access control, all slightly differently because I was writing them by hand each time instead of from a shared system.

The Solution #

Switched to Payload CMS, defining each content type as a schema (a "collection" in Payload's terms) instead of a hand-built form. Payload generates the admin UI, validation, and API from that schema.

export const ServicePages: CollectionConfig = {
  slug: "service-pages",
  fields: [
    { name: "title", type: "text", required: true },
    { name: "body", type: "richText" },
    { name: "published", type: "checkbox", defaultValue: false },
  ],
};

Why It Works #

Defining content as a typed schema means the admin UI, the REST/GraphQL API, and validation are all generated from one source of truth instead of hand-maintained in three places (form, API route, database model). Adding a sixth content type is a schema definition, not a new subsystem.

Lessons Learned #

The cost of a hand-rolled admin panel doesn't scale linearly with content types — it scales worse, because every new type re-pays the same "forms, validation, access control" tax. A schema-driven CMS trades some flexibility for making that cost roughly constant.

What I Would Do Differently #

I'd evaluate a schema-driven CMS before writing the first custom admin form, not after building one and recognizing the pattern was going to repeat five more times.

Related Concepts #

Schema-as-code content modeling, headless CMS architecture, generated admin UIs.