“A marketing team wants to launch a new campaign page type.. Something that used to take 30 minutes took 30 seconds. They looked at the old way and couldn't believe they'd tolerated it. That was the aha.”
When I'm a marketing team wants to launch a new campaign page type, I want to design content models that are flexible enough for editors but structured enough for the frontend, so I can build a preview system so editors can see content changes before publishing.
A frontend or full-stack developer who integrates Contentful as the content backend for a website, app, or digital experience. They set up the content models, build the delivery layer, and create the bridge between what content editors want to publish and what the frontend can render. They appreciate the API-first approach but have learned that "headless" means they're responsible for everything the CMS traditionally handled — routing, preview, caching, image optimization. They build the head.
To design content models that are flexible enough for editors but structured enough for the frontend — reliably, without workarounds, and without becoming the team's single point of failure for contentful.
A frontend or full-stack developer who trusts their setup. Design content models that are flexible enough for editors but structured enough for the frontend is reliable enough that they've stopped checking. Content model versioning with migration tools that don't break the frontend on schema changes. They've moved from configuring contentful to using it.
A marketing team wants to launch a new campaign page type. The developer designs a content model: hero section, feature grid, testimonial carousel, CTA block — all as modular components the editor can arrange. The editor loves the flexibility. Then they ask for a layout option the content model doesn't support — a full-width video background. The developer has two choices: extend the content model (which affects every existing page of that type) or create a one-off content type (which adds maintenance burden). They choose a compromise — an "embed block" component that's flexible but requires the editor to paste HTML. The marketing team is mildly disappointed. The developer is mildly concerned.
Manages Contentful for 1–3 projects (marketing site, documentation, app content). Has designed 10–30 content types with varying complexity. Uses the GraphQL or REST API for content delivery. Has built custom preview environments for editorial workflows. Handles content migrations when models change. Integrates with Next.js, Gatsby, or a custom frontend. Manages 3–10 content editor accounts with role-based access. Spends 10–20% of development time on CMS-related work.
Two things you'd notice: they reference contentful in conversation without being asked, and they've built workflows on top of it that weren't in the original plan. Design content models that are flexible enough for editors but structured enough for the frontend is consistent and expanding. They're now focused on build a preview system so editors can see content changes before publishing — a sign the basics are solved.
It's not one thing — it's the accumulation. Content model changes after launch can break the frontend if not carefully migrated that they've reported, worked around, and accepted. Then a competitor demo shows the same workflow without the friction, and the sunk cost argument collapses. Their worldview — content and presentation should be completely separate — but "completely separate" creates integration challenges someone has to solve — makes them unwilling to compromise once a better option is visible.
Pairs with contentful-primary-user for the standard CMS perspective. Contrast with sanity-primary-user for the real-time collaborative CMS alternative. Use with webflow-designer for the monolithic vs. headless CMS philosophy comparison.