# Uncollected Thoughts On Contentful

URL: https://tannergodarzi.com/blog/uncollected-cms-thoughts
Published: 2026-02-17

Choosing a CMS comes down to knowing your tradeoffs and picking the one that fits how your team actually works. Having scaled Contentful from small site installs — [https://dropbox.design](https://dropbox.design/) — to Notion's marketing site and page builder, I've found it holds up well, especially in a Next.js setup with a clear path to handle startup hyper growth.

## Headlessness

An unopinionated CMS that outputs raw JSON gives you the most flexibility. Your content has no CMS-specific structure baked in. Assuming your CMS could disappear tomorrow instills a healthy paranoia. It forces you to export and consume JSON in a way that's portable—valuable if you ever need to migrate to a different CMS or own your data in a doomsday scenario. I’ve yet to evaluate the need for this, but vendor lock in is a thing I don’t like relying on.

Localization and integration with Translation Management Systems is seamless with Contentful. Next.js in an App Router configuration requires you to write the entire localization layer yourself, preventing easy localized routes out of the box. Thankfully, we've solved this problem at Notion — more thoughts there soon.

## Contentful Gotchas

**Query depth and Nested references**

Contentful's query calls not only become more expensive as linked entries are pulled in, but it's easy to fall into a circular reference loop that blocks a successful build. Keeping Content Types and entries as flat as possible mitigates this while giving flexibility for building new marketing site surfaces that can function more independently of each other.

**Data parsing**

Next.js will hard fail on consuming `undefined` in a props return. Contentful eagerly returns `undefined` if a query fails to fetch content. Data sanitization is not optional—you need a data formatter per content type to handle missing fields and prevent breakages.

**Vercel Caching or caching at Build?**

Depending on the size of your site and how fast you need to deploy, you might consider blocking builds if static pages fail to render. This slows shipping dramatically and turns publishing mistakes into incidents, even if Contentful allows the change. But a production-facing failure isn't catastrophic if your caching layer returns a last-known-good version when a route 500s. With proper alerting, you can give yourself time to debug content issues without causing outages.

**Next.js Caching**

Next's caching is all-or-nothing by default on dynamic routes. Pages under `http://site.com/blog/[slug]` stay cached for up to 30 minutes, meaning rapid updates require manual cache invalidation.

**Vercel Caching On Edge**

Not all content needs cache invalidation the moment it's published. You can save compute time by letting some pages live with longer cache windows. Production deploys will bust the entire cache, but at scale, a standalone cache layer between Contentful and Vercel makes sense. Pages like help articles and release notes can safely live with 1–24 hour cache windows. Next.js provides per-route instant cache invalidation, which lets important updates propagate immediately when you need them to.

## How Would I Use Contentful With Next?

A mostly server-side rendered configuration with long cache times — pages render at request time then cache aggressively as if they were static — paired with per-route cache invalidation that anyone can trigger. Contentful scales well with shallow query depth and batched content changes (like translations). Aggressive data sanitization and a per-content-type formatter reduces complexity and prevents the common Contentful issues.