Content management integration
Headless CMS Integration
Contentful, Sanity, Strapi, Payload or WordPress as a headless source - wired into the App Router with typed content, caching that matches how editors work, and preview that keeps the cache.
A headless CMS integration goes wrong in the same three places every time, and none of them is the CMS. The content is untyped, so a field rename becomes a runtime error in production. The caching is wrong, so editors publish and wait. And preview either does not work or works by making every route dynamic.
What we build
Typed content, end to end. The CMS schema generates TypeScript types, and
the fetch layer parses what comes back rather than asserting it. A renamed
field then fails at the build or at the edge with a message that names it -
not three components later as undefined is not a function.
Caching that matches how editors work. Content is tagged, not
time-revalidated. A webhook from the CMS clears the tag for what changed, and
the page updates in seconds without making the route dynamic. The alternative -
revalidate: 60 everywhere - means editors wait a minute and your origin
takes traffic it did not need to.
Preview that does not cost you the cache. Draft mode on the preview route only, scoped to the editor's session, so the published route stays static for everyone else. Editors see unpublished content; visitors get the CDN.
A block model that survives. Most projects model content as pages with fixed fields, and then marketing asks for a layout the model cannot express. We model composable blocks from the start, with the renderer typed against the block union so an unhandled block is a compile error rather than a blank space.
Which CMS
We are not tied to one, and we will tell you when the one you picked is wrong for what you are doing - but this is rarely the interesting question. The integration is most of the work and it is largely the same shape whichever you choose.
If you are migrating off WordPress and keeping it as the editing surface, that works: WordPress as a headless source with Next.js rendering is a legitimate architecture and often the cheapest path, because the editors keep the tool they know.
What we need from you
Access to the CMS and someone who can answer "what is this field for". The second is more important than the first - a content model that mirrors an old template rather than the actual content is the thing that makes the rebuild expensive, and it is worth an hour of conversation before any code.