The 5 unbilled months hidden in every Contentful enterprise build

On day one, editors paste full URLs into rich-text fields and CTA buttons. It works in staging, ships to production, and quietly rots. The first slug refactor — six months in, when SEO finally weighs in — breaks 200 entries silently. Now the team writes a one-off scanner. Then a one-off fixer. Then a one-off CMS migration. That is a month.

The fix is not exotic. A typed linkReference field that points at the target entry, resolved at fetch time. Same UX in the editor, no string anywhere. Three days to design, two weeks to retrofit across every block, two more weeks to migrate the existing rich-text content. Five weeks. The team books it as 'content cleanup'.

There is no redirect engine in vanilla Contentful. Every URL change becomes an engineering ticket: edit a config file, open a PR, deploy. Marketing waits a sprint to retire a campaign URL. The SEO team learns not to ask. Four months in, somebody finally builds it: a redirect content type with regex/wildcard support, evaluated at the proxy edge, plus a webhook that auto-writes a redirect entry whenever an editor renames a slug.

It is two weeks of senior work, plus another two weeks of catching the slug changes that already broke. A month, gone. The team books it as 'SEO infrastructure'.

The project starts with one locale and 'we'll add more later'. Later arrives, and the foundation is missing: no fallback chain (a Danish entry with no Danish copy returns null), no localized slugs (URLs stay English in every market), no CMS-driven dictionaries (UI strings live in JSON files marketers cannot touch). The localization vendor sends translations and discovers there is nowhere to put them.

Building it properly is a month: locale fallback baked into every CMS query, localized parent and child slugs, hreflang generation, default-locale URL hiding, and a localizedDictionary content type with token interpolation. The team books it as 'translation work'.

Marketing wants a new lead-capture form for a campaign starting Monday. The current setup hardcodes forms into React components. Engineering ships a release for every field. By month four, somebody has had enough and rebuilds it: a form content type with a typed field schema, a single renderer, validation rules in the CMS, and an action endpoint that writes to whatever your CRM happens to be.

Three weeks to build, one week to migrate the existing forms, one week to train marketing on the new editor UI. A month. The team books it as 'marketing platform'.

By month five, the codebase is full of fields.title.en-US and fields.body.fields.content[0].fields.text. A field rename in Contentful breaks runtime in production. A junior engineer ships a regression nobody catches. The team finally bolts on graphql-codegen against the live CDA schema, with a drift detector that fails CI when types and CMS diverge.

Two weeks to wire the codegen pipeline, two weeks to retrofit every fetch site, one week to fix the bugs that the new types surface. A month. The team books it as 'tech debt'.

These five months are not a sign of a bad team. They are a sign that vanilla Contentful does not ship a production foundation, and the foundation is the same on every project. Either you build it once, slowly, on each new build — and pay senior salaries for it every time — or you adopt a foundation that already has all five solved.

Our Contentful enterprise starter for Next.js 16 is the productized version of those five months. Dynamic link references. A redirect engine with auto slug-change webhooks. Real internationalization. Schema-driven forms. End-to-end type safety with drift detection. Delivered as source to your repo, perpetual license, no SaaS.

If your last build hit four of these five, the next one will too. Plan accordingly.