CMS & Next.js Frontend

When designing this site, I had two priorities: keep costs low and stay flexible for future growth. That led me to a static website architecture using Next.js on the frontend, paired with PayloadCMS for content management.





Why This Architecture?

  • Static = Cheap
    The site is pre-rendered and served via CDN—so it runs fast and costs nothing by using the free-tier of a Content Delivery Network.
  • CMS = Scalable
    A CMS separates content from code, making updates easier and future collaboration possible.
  • PayloadCMS = Something New
    I’ve used Strapi before, but wanted to try something different. PayloadCMS allowed me to explore new patterns and tools.



Two Workflows to Know

There are two key workflows that come together to build this site:

1. Designing the Website

Next.js handles this. It’s responsible for:

  • Styling – layout, responsiveness, and component design
  • Page Structure – how pages are built and displayed
  • Rendering Logic – telling Next.js how to generate each page statically

This is where all the visual and interactive pieces of the site live.

2. Writing the Content

This is handled by PayloadCMS, which runs locally during development. It manages:

  • Content – blog posts, page bodies, headings, etc.
  • Schema – how content types are structured (e.g. pages, posts)
  • Relationships – linking pages, tags, authors, and other fields together

With PayloadCMS, content is decoupled from code, freeing the frontend to consume content via an API. A good overview of the concepts can be found here.



How it all connects

Here's a high-level view of the data and build flow:

Developer Process

Key notes:

  • The CMS runs only during development.
  • The database is stored as a file and committed to Git to simplify local dev.
  • At build time, Next.js pulls all content from PayloadCMS and generates static pages.

To help orient you, here are the key files in the frontend stack:

  • content.ts – Handles API calls to PayloadCMS to fetch content (e.g. pages, blog entries).
  • page.tsx – Converts content into JSX components. This is where we render things like rich text, banners, or column layouts from CMS data.
  • layout.tsx – Assembles the full page using the components from page.tsx, wrapping everything in site-wide structure like headers and footers.

Note: JSX components can (and should) comprise smaller subcomponents. For example, a Columns block might be built from several Card or ImageText components. Keeping things modular makes it easier to maintain and reuse.


Let's start by getting a PayloadCMS and next.js project running using the scaffolding processes provided by both platforms.