I recently spent time exploring Payload CMS while looking for a better content-management option for custom websites. Most CMS choices seem to force an early compromise. A traditional platform gives editors a familiar admin area but can make custom application logic awkward. A headless service gives developers a clean API but places the content system, application, and hosting in separate worlds. Payload caught my attention because it approaches the problem as a TypeScript-first application framework that can live directly inside a Next.js project. It feels less like connecting someone else's dashboard to my site and more like adding a capable content layer to the application I already want to build.

The Next.js integration changes the mental model

Payload installs into the same Next.js App Router project as the frontend. Its admin panel and API routes occupy their own route group while the public site remains part of the same application. That arrangement immediately made sense to me. The CMS does not need to be treated as a distant service with a completely separate deployment story. Frontend components, server-side content queries, configuration, and custom application code can share one repository and one TypeScript environment. For a full-stack developer, fewer artificial boundaries make the whole system easier to understand.

The content model lives in code

Payload is configured through code. Collections, fields, validation, hooks, authentication, and access rules are defined explicitly instead of being assembled only through a production dashboard. I like this because the content model becomes part of the software rather than hidden configuration. It can be reviewed, versioned, tested, and changed alongside the components that consume it. A posts collection can describe its title, slug, author, rich content, publication state, and permissions in one readable place. The generated admin interface then follows that schema, giving editors structure without asking developers to rebuild basic content screens.

The Local API fits server-rendered React

The feature that made Payload feel especially natural with Next.js was its Local API. A React Server Component or route handler can query Payload directly on the server without making an HTTP request back into the same application. The operations remain familiar—find documents, create content, update records, and apply query filters—but there is no unnecessary network boundary. REST and GraphQL are still available when another application needs them. This gives the project a simple fast path internally and conventional APIs externally, rather than forcing every consumer through the same route.

Editors still get a real content workflow

A developer-friendly CMS is only useful if non-developers can comfortably manage the content. Payload generates an admin panel from the same collection definitions and supports the workflow features I would expect for a client site: rich fields, uploads, relationships, drafts, autosave, scheduled publishing, and live preview. Live preview is particularly valuable for visual websites because an editor can see the frontend respond while content changes. It closes the gap between a structured form and the designed page without turning layout control into an unrestricted page builder.

Authentication and access control belong near the data

Payload can enable authentication on a collection and define access rules for reading, creating, updating, and deleting content, including rules at field level. That opens possibilities beyond a public blog: team roles, private resources, customer areas, or content that changes according to the current user. I also noticed an important detail in the Local API documentation: server-side operations bypass access control by default unless access enforcement and a user are supplied. That power is useful for trusted server tasks, but it also makes the security boundary something a developer must understand rather than assume.

Database choice stays with the project

Payload currently provides official database adapters for MongoDB, PostgreSQL, and SQLite. I appreciate that the CMS does not require every project to accept the same storage model. A content-heavy build with flexible nested structures may suit MongoDB, while an application with strong relational requirements may benefit from PostgreSQL. SQLite can keep a smaller project simple. The decision still needs to account for hosting, migrations, backups, relationships, and expected traffic, but choosing the database as part of the architecture feels more honest than inheriting it from a hosted CMS without discussion.

It is more than a blog backend

My first thought was to use Payload for posts and pages, but its collections, relationships, hooks, authentication, file uploads, and API layer make it capable of supporting much more. A portfolio could manage case studies and media. A studio site could connect services, team members, testimonials, and localized pages. A product application could combine editorial content with authenticated data and custom workflows. The useful part is not having every feature switched on. It is being able to grow the content system without immediately replacing it when the website becomes more application-like.

I would not use it for every website

A static portfolio with content changed by one developer may be clearer with local data or Markdown. A client already comfortable in WordPress may value continuity more than a new stack. Running Payload also means owning its database, media strategy, migrations, security, deployment, and upgrades. Those are advantages when the project needs control, but unnecessary responsibility when it does not. I see Payload fitting projects where editors need a good admin experience and the application needs custom behavior, structured content, or room to grow.

Why it stayed on my shortlist

What I found great about Payload CMS is the alignment between the editorial experience and the development experience. Editors get a purposeful admin panel, drafts, and preview tools. Developers get TypeScript configuration, direct server-side queries, generated APIs, access control, and database choice inside a familiar Next.js project. I am still approaching it as a tool to evaluate carefully rather than a default answer, but it solves the CMS problem in a way that matches how I already think about full-stack applications: keep the data model explicit, keep important boundaries under control, and make the final system comfortable for both the people building it and the people using it.