Content editing for Next.js with Payload CMS

In this short article, we share our experience using Payload CMS, a very promising content editing system for the Next.js framework, which we decided to adopt for managing content on the Inmagik site, already built on Next.js.

Brief Introduction to Payload CMS

Payload CMS is a headless / “hybrid” CMS written in TypeScript, designed to be embedded directly into a Next.js app. It offers REST / GraphQL APIs and a ready-to-use admin panel. You can define relational data models for your site content, and it provides intuitive and efficient APIs for integrating this content into your frontend.

Why We Moved from Static Content to Payload

Until now, we managed Inmagik’s site content with JSON and Markdown files: simple and very efficient in terms of response time, but with limitations — every change required a new deploy, SEO management was manual, and more structured content was hard to maintain.
By choosing to migrate to Payload, we aimed to achieve a more agile, dynamic, and integrated content management process.

Benefits We Observed

• Seamless integration with existing Next.js
  Payload can be inserted into the structure of the site without requiring a separate backend or a radically different architecture.

• Data models defined in code (code-first / declarative)
  Defining collections, fields, and relationships directly in code (TypeScript/JavaScript) improves clarity, versioning, and consistency.

• Server-to-server data access, bypassing HTTP
  Payload provides a “local API” that lets the Next.js server query the data directly without going through external HTTP endpoints, reducing latency and complexity.

• Ready-to-use administration panel
  We didn’t have to build a CMS interface from scratch: the dashboard is ready, customizable, and usable immediately.

• Support for multiple databases + storage on S3 / external services
  Support for various databases (PostgreSQL, MongoDB, etc.) and the ability to store files in external buckets (e.g. S3) satisfied essential requirements for us.

• Abstract fields and “Blocks” for flexible content
  The blocks field lets you build content with a customizable but controlled structure, adaptable to design while retaining constraints and consistency.

Weaknesses and Limitations We Encountered

• Mixed semantics between data model and editing UI
  In Payload, model definitions tend to overlap data structure with editing interface configuration (labels, UI components, admin behavior). It’s powerful and convenient, but can feel like there’s less clear separation of control compared to “purer” models like those we use in Django.

• UI is rational but not always intuitive for nontechnical users or highly complex models
  The interface is clean and logical, but when models become intricate or users are unfamiliar, the learning curve can be a barrier.

• Lack of some out-of-the-box features and possible documentation gaps
  Some edge cases or advanced features require custom implementation (or plugins), and while the documentation is good, it may be less complete for “nonstandard” scenarios.

• Admin scalability with large models / complex relations
  If the number of fields, relations, or customizations grows considerably, the admin UI may begin to exhibit usability constraints.

Conclusion: Our Satisfaction and Future Plans

The migration has been positive: with Payload, we gained more direct control over site content (including SEO management), while keeping a simplified stack based solely on Next.js.

We are considering using Payload in other Next.js projects where the data model fits well within the standard interface. For more complex projects, however, we will continue to implement custom admin interfaces to guarantee better usability of the user interface.