Contentful development for content at enterprise scale - where coordination is the hard part, not content.
Intention InfoService builds on Contentful - modelling your content, wiring the governance and delivery, and building the fast front end that reads it in Next.js or Astro - by a small senior team at transparent published fixed prices. Contentful earns its keep at enterprise scale, where content stops being a writing problem and becomes a coordination problem: many teams, brands, locales and channels shipping at once. You own your content and your content model, exportable through the Content Management API or the CLI whenever you want; the platform itself is Contentful's hosted service you pay for directly. For startups, SMBs and enterprises worldwide.
Fixed price, content you own, no in-house lock-in.
- Your content, yours and exportable
- Published fixed pricing
- Governance and orchestration at scale
Contentful in 2026Enterprise
- Model
- Content types, references, Rich Text
- Governance
- Environments, Merge, roles, releases
- APIs
- CDA, CMA, CPA and GraphQL
- Delivery
- Next.js or Astro reads it
Contentful is the content backend - your front end reads it, and many teams govern it.
Contentful implementation, integration, and the front end that reads it
Contentful is the content backend - we model your content, stand up the governed platform, integrate it into your stack, and pair it with a front end that renders fast. A typical Contentful engagement is one of these:
Content modelling and architecture
The foundation: your domain modelled as typed content types with validations, references and a real content graph - shaped around how your teams and channels actually use the content, so an editor cannot break the shape and a front end can trust it.
Contentful implementation
Spaces, environments, roles and the delivery setup stood up as a governed platform: the content model in code, the APIs wired, and the editorial workspace configured so your teams publish the way they actually work, not the way a default admin assumes.
Integration into your stack
Contentful connected to the rest of your systems through the App Framework and Marketplace apps and through webhooks - translation and DAM, search, commerce and analytics - so content flows into and out of the platform instead of living on an island.
The front end that reads it
Contentful is the backend; the site is a front end that reads it over the Content Delivery or GraphQL API - Next.js for app-grade and SEO-critical sites, Astro for content sites - with preview builds off the Preview API and on-demand revalidation on publish.
Governance and editorial workflow at scale
Roles and permissions, tasks and comments for review, scheduled publishing and releases so related changes ship together, localization for many markets, and orchestration across spaces and brands - wired to your real approval process.
Migrations onto Contentful
Moving off a legacy CMS onto structured content: we model the target first, script the extract and transform through the Management API, load into a non-production environment to verify content and references, and map URLs with redirects so the SEO survives the cutover.
Contentful is the backend - here is what reads it, and when it is more CMS than you need
Contentful does not render your website; it stores, governs and serves your content. The site is a front end, and sometimes Contentful is more platform than the job needs - here is where each of those goes:
The front end for an app or an SEO-critical site - Next.js, the React front end that reads Contentful is where that build happens - server rendering, on-demand revalidation from Contentful, and the interactivity of a real application. Contentful models, governs and stores the content; the site itself is the front end.
The front end for a fast content or marketing site - Astro, a fast content-site front end over Contentful is the leaner pairing when the site is mostly static content - Astro reads Contentful as its source and ships almost no JavaScript. We build both front ends and pick the fit.
Your content is really a single team editing one site - Sanity, a leaner headless CMS is the developer-first, lighter-weight structured backend for that shape. Contentful's governance and enterprise plan earn their keep when many teams coordinate; below that scale, a leaner CMS is the honest call.
You want to own and self-host the running software - Strapi, the self-hosted headless CMS you own is the route when owning the software itself matters - Contentful is hosted SaaS, so you own your content, not the platform that runs it.
A team that just wants to edit whole pages in a familiar admin - WordPress, the traditional page-based CMS is often the right, cheaper call - a themed admin your team already knows. Contentful earns its keep when content is structured, reused and governed across many surfaces, not when one team edits pages in place.
At enterprise scale, content stops being a writing problem. It becomes a coordination problem.
Every headless CMS can store a typed model and serve it over an API. That is table stakes, and it is not, by itself, a reason to choose Contentful. What Contentful is actually built to solve shows up only at scale, when the bottleneck stops being "can we structure this content" and becomes "how do many teams, brands, locales and channels all ship changes at once without stepping on each other." That is a coordination problem, and coordination is what Contentful engineers into the platform: environments and Merge give you git for your content model, and orchestration, governed visual assembly and releases let a large organization run many properties in parallel. The honest flip side is the whole point of this page - that apparatus, and the enterprise plan that comes with it, is worth every bit of its cost at that scale and overkill below it. If your content is one team writing for one site, you would be paying for coordination you do not have to do, and we would route you to something leaner.
What a composable content platform gives you at scale
Contentful is built on one idea - content operations that many teams can run at once - and everything below follows from it. Here is what that buys you, and, honestly, when a leaner tool is the better call.
Git for your content model
Environments are full, isolated copies of your model and data. You branch one, change the schema safely, review the diff and promote by repointing an alias - the same release discipline your code already has, with rollback as cheap as pointing the alias back. Merge computes the changeset between two environments so a model change is reviewed, not hand-applied to production and hoped over.
Who ships what, reviewed, and when
Roles and permissions scope who can edit or publish, down to content types and fields; tasks and comments make review an explicit, tracked step; scheduled publishing lands a campaign at a set time; and releases bundle related changes so a launch's page, banner and nav go live together instead of leaking half-finished.
Assemble pages without breaking the brand
Studio and Experience Builder let content teams assemble pages from design-system components you register - components with defined props, bound to structured content, inside the same review governance. It is governed visual assembly, not a free-for-all page builder, so marketers move fast while brand and structure hold.
One source, many channels
Orchestration connects content across environments, spaces, brands and channels: a parent brand pushes a shared component or policy to a dozen sub-brand spaces, and one content set fans out to web, app and commerce without being re-authored per surface. Content changes propagate by reference, not by a hundred manual edits.
Built for many markets
Locales are first-class: fields localize per market, fallbacks fill the gaps, and translation workflows plug into the same review and publishing governance. A page exists once as a structured entry with per-locale values, not as forty forked copies that drift apart the day after launch.
Structured, so it moves
Content is typed data served over purpose-built APIs, exportable through the Management API and CLI. Combined with an approach that stays standard Contentful, the parts that encode your work stay portable and in your hands - the platform is rented, but the content is yours to take.
When Contentful is more CMS than you need
Contentful is a lot of platform, and that is a reason to walk away as often as a reason to buy. If your content is one small team writing for one site, the governance and the enterprise plan are weight without payoff, and a leaner, developer-first structured backend like Sanity is the honest call. If owning and self-hosting the running software matters more than a managed service, that is Strapi. And if your team just wants to edit whole pages in a familiar admin, that is WordPress. Not sure which side of that line you are on? We will make that call with you before we quote.
Enterprise content governance, from environments to orchestration
There is no Contentful running this Next.js site to point at, so the proof is the discipline. Everything here is a decision you can inspect on a build we deliver - a content type, an environment workflow, an API choice - which is the point: you should never have to take our word for what a well-run Contentful platform looks like.
Typed content models
We model your domain as content types with typed fields and validations - required flags, ranges, patterns, allowed values and which types a reference may point at - so an editor cannot violate the shape by accident and the front end can trust that a product always has a price of the right type. What you check: the model is an explicit contract, not free text.
References and the content graph
Entries reference other entries, so an article points at an author and a landing page composes a list of section blocks - a graph, not a pile of pages. Cross-space references let a shared library of brand assets or global components live in one space and be consumed by many, so a disclaimer or token is authored once and reused everywhere.
Rich Text as structured JSON
The Rich Text field stores a structured JSON document - nodes, marks and embedded entry references - not a pre-baked HTML string. The front end decides how every heading, list and embedded component renders, so the same authored paragraph becomes semantic React on a website and clean markup in an email, from one source.
Four purpose-built APIs
We match the API to the job rather than force one to do everything: the Content Delivery API serves published content fast to the live site, the Content Preview API serves drafts to a preview build, the Content Management API is the write and automation surface for migrations and integrations, and the GraphQL Content API asks for exactly the fields and linked entries a view needs in one round trip.
Environments, aliases and Merge
This is the capability that separates Contentful from a database with a nice editor. An environment is an isolated copy of the model and data; we branch it, evolve the model there while production keeps serving, then promote by repointing an alias - no code change, and rollback as cheap as pointing it back. Merge computes and applies the changeset between two environments, so a model change is reviewed and promoted like code.
Roles, tasks, publishing and releases
Roles and permissions scope who can edit, publish or only comment, down to specific content types and fields. Tasks and comments turn review into a tracked step on an entry; scheduled publishing lands a change at a set time; and releases group related entries so a product launch's page, banner and nav publish together, atomically, instead of leaking half-finished.
Governed visual assembly
Contentful Studio and Experience Builder give content teams a visual canvas where they compose pages from design-system components that we register - components with defined props, bound to structured content, inside the same roles and review governance. The distinction that matters: this is assembly constrained to the approved component library, so brand and structure hold while marketers move without a developer in the loop.
Orchestration across brands and channels
Contentful's orchestration connects content across environments, spaces, brands and channels and manages apps centrally in any environment. In practice that is a parent brand pushing a shared component or policy to many sub-brand spaces, or one content set fanning out to web, app and commerce without being re-authored per surface - the coordination layer a single site never needs and a multi-brand enterprise cannot live without.
Localization at scale
Locales are first-class: a field localizes per market, fallbacks define what an unfilled locale inherits, and translation workflows - human or connected translation-vendor apps - plug into the same review and publishing governance. A page exists once as a structured entry with per-locale values, and a structural change reaches every locale at once, not forty forked copies that drift.
Personalization and AI, as Contentful's own
Personalization runs through Contentful's own capability (built on its Ninetailed acquisition), letting editors define audiences and variants against structured content. Contentful also ships its own AI inside the workspace - model, content and image generation. These are Contentful's platform features that we wire and govern; we do not rebrand them as an AI service of ours.
App Framework, webhooks and revalidation
The App Framework lets us extend the editor itself - custom field editors, sidebar widgets, dashboards - and the Marketplace supplies ready integrations for translation, DAM, analytics and commerce, so the editing experience fits your workflow. On the outbound side, webhooks fire on publish and drive on-demand revalidation, so a Next.js or Astro front end updates the exact affected pages the moment content changes - no full rebuild, no stale cache.
Migrations onto Contentful
Moving onto Contentful is a defined engineering sequence, not a copy-paste: we model the target content types, script the extract and transform from the legacy source through the Management API, and run the import into a non-production environment where we verify counts, references and rendered output before anything touches production. URL mapping is locked before cutover so SEO equity survives the move.
How we take on a Contentful build: model the content types first, because every later decision inherits from the model; stand up environments, roles and the editorial workflow as a governed platform; wire the APIs and the webhooks; then build the front end that reads it in Next.js or Astro, with on-demand revalidation so a publish refreshes only the affected routes. And when the content is really one team editing one site, we will tell you that is a leaner CMS's job, not Contentful's.
We wouldn't put our own site on Contentful - and that is the recommendation working.
No Contentful build lives on this domain, and there is a fit reason, not an excuse. Our site is one small team's content - a handful of pages, one voice, one release at a time - and that is exactly the case where Contentful's enterprise governance is weight without payoff, so we would steer ourselves toward something leaner. That is the same call we would make for you if your shape were ours. (For the record, our own blog, guides and glossary run on Sanity, not Contentful, so Contentful is a permanent zero on our own domain.) We show no performance numbers for a Contentful build here; any speed figures on this site belong to our own Next.js build and would not honestly transfer to work we have not shipped.
The depth on this page is the demo
We won't tell you we "ship Contentful," because we have not shipped one yet, and saying otherwise would be the exact overclaim this page exists to avoid. What we can stand behind is knowledge: we are people who know current Contentful practice cold - environments and aliases, Merge across environments, roles and tasks and releases, the four purpose-built APIs, governed visual assembly, and orchestration across spaces and brands. When you have no logos to point at, the honest proof is that you can explain the platform better than the pitch decks can, and every claim here is a decision you can inspect on a build we deliver, not a number you have to believe.
You own your content and content model, not the platform
Here is the honest line on lock-in, drawn the same way we drew it for a hosted store. Your content and your content model - the type definitions, entries, assets and relationships - are yours and exportable at any time through the Content Management API or the CLI, and the front-end code we write is yours too. What you do not own is the running platform: Contentful is a hosted service you rent, billed to you directly by Contentful. We will not tell you that you own the platform, and we will not wave away switching cost with a flat 'no lock-in' - it is a SaaS backend. The honest version is better: your content is portable and yours, the software that serves it is theirs, and you choose it knowing exactly which is which.
Standard Contentful, no in-house layer
We build on Contentful the way Contentful ships it - standard content types, the documented APIs, the App Framework where an extension genuinely helps - not a proprietary layer only we understand. Wrapping your content in a bespoke framework would quietly convert Contentful's lock-in into ours, so we don't. Any team fluent in current Contentful practice can pick up the space and keep going without us in the room.
We adopt or migrate after an audit
Most teams that call us already have content somewhere - a legacy CMS, a pile of pages, another headless tool. We don't start by ripping it out. We start with a paid audit, model the target on Contentful, script the extract and transform, and verify the result in a non-production environment before anything is served, with URLs mapped and redirected before cutover. You watch the migration prove itself in a safe environment first.
Senior people, direct, since 2016
You talk to the engineers who model your content and wire the governance - no account-manager layer, no offshore hand-off, no juniors learning Contentful on your budget. Intention InfoService is a real, incorporated company, small and senior on purpose, so the content model stays consistent from build to deploy, at published fixed prices billed against clear milestones, with an NDA on request.
Honest about partners, certifications and attestations
Contentful runs a Solution Partner program with a public partner directory - and we are not a Contentful Solution Partner and are not listed in that directory; name it, so you can check it. On certification: there is no company-level or agency-level Contentful certification to hold. Contentful's certifications are individual credentials a person earns, issued as verified-skill badges, not a badge a company carries - so 'we are certified' would be a category error, and we won't claim it. Any SOC 2, ISO or similar attestation you have seen is Contentful's, held by the platform as a vendor feature, never ours. For our own part, we hold no SOC 2 report and no ISO 27001 certification, and there is no HIPAA certification for anyone to hold; SOC 2 is an attestation report, not a certification, and we describe it that way every time.
No markup, and no score we invented
You pay Contentful directly for the platform, on their own plan - a genuine free tier to explore, paid plans scaling by spaces, users, locales and usage up to a custom enterprise plan - and we take no referral markup that could quietly shape what we recommend; our fee is for the build. And we will not show you a Core Web Vitals or Lighthouse score for a Contentful build that does not exist yet. Performance is engineered on your real content and measured on your real pages after launch.
The real work behind this honesty
We have not shipped a Contentful build, so we will not dress one up. What we can show you is the problem shape Contentful is built for, already solved in production on our own stack. Our production work is real, custom full-stack Next.js builds - a professional-training platform rebuild and a financial-services site. The training platform is a WordPress-to-Next.js rebuild that models a large course catalog once - courses, cities, categories, relationships - then serves that single model to many surfaces at once: a fast filterable catalog, templated per-city course landing pages, demo-class and enquiry funnels, and a headless CMS the marketing team runs itself. The financial-services site does the same with structured pages for ten loan categories, a real-time EMI calculator, and apply enquiry funnels. Model the content once, serve it to many surfaces, keep it coherent as it changes: that is the coordination job Contentful scales up across teams, brands and channels. The tool would differ; the discipline is the one we already practise. You can walk the two builds where one model already feeds many surfaces and see a team that ships real web software - never a Contentful case study we don't have. The Contentful-specific proof is the current-standard depth on this page and the standard, exportable Contentful content you would own outright.
How we implement Contentful - and migrate onto it without breaking SEO
The content model and the governance are the foundation the delivery sits on, so we build them first - and most Contentful builds go from kickoff to live in weeks, not months.
Model the content types first
firstBefore any UI, we design the content model - typed content types, fields and validations, references and the content graph - agreed as the contract everything downstream inherits from. Getting the model right is the decision that decides whether the next three years are calm or painful.
Stand up governance
the platformWe set up spaces and environments, define roles and permissions down to types and fields, and wire the editorial workflow - tasks and review, scheduled publishing, releases and localization - to how your teams actually approve and ship. This is the coordination layer, configured to your reality, not a default.
Wire the delivery
the buildWe connect the front end - Next.js for app-grade and SEO-critical, Astro for content sites - reading Contentful over the Delivery or GraphQL API, with drafts served through the Preview API. Webhooks fire on publish and drive on-demand revalidation so an edit refreshes exactly the affected routes within seconds.
Migrate in a safe environment
on a moveFor a move onto Contentful we script the extract and transform through the Management API and run the whole import into a non-production environment, where we verify counts, references and rendered output before anything touches production. URLs are mapped and redirects planned before cutover, so the SEO survives the move.
Release, and hand over
on deliveryWe release by repointing an environment alias at the tested environment - no code change, instant rollback by repointing back - and hand you a governed Contentful space and a front end you own, documented, with the model, the workflow and the revalidation wired. What you keep is standard, exportable Contentful.
Contentful, a leaner CMS, or page-based? Match the platform to your scale
We're stack-agnostic, so this is fair, not a pitch. The real choice is not brand versus brand - it is how much content governance you actually need, and at what scale.
| Enterprise composable platform (Contentful) | A leaner headless CMS | A traditional page-based CMS | |
|---|---|---|---|
| Content shape | Typed, reusable data, orchestrated across brands | Typed, reusable data you query | Pages edited in a themed admin |
| Who coordinates it | Many teams, with roles, review and releases | A team, once developers model the schema | A team, in a familiar admin |
| Model & release control | Environments, aliases and Merge - git for content | Datasets or a self-hosted stack, lighter process | Edit live, or a plugin-based workflow |
| Scale it fits | Many teams, brands, locales and channels at once | One to a few teams and surfaces | One team editing one site |
| Front-end freedom | Any front end you build (Next.js, Astro) | Any front end you build (Next.js, Astro) | The theme, or headless with work |
| Best when | Content is a coordination problem across the org | Content is structured but the team is small | One team edits one site, simply |
Contentful earns its keep when content is a coordination problem across many teams, brands and channels, and it is overkill below that scale. A leaner headless CMS like Sanity sits in the same structured, headless family - developer-first and lighter-weight - and Strapi is the self-hosted route when you want to own the running software. When a single team just edits pages in a familiar admin, a page-based CMS like WordPress is the simpler, cheaper call. We recommend the fit, not a badge we hold.
Is Contentful still a good choice after the Salesforce acquisition?
A material platform fact, stated the way we would want it stated to us - not as news, and not as a reason to panic or to celebrate.
In mid-2026 Contentful announced it had signed a definitive agreement to be acquired by Salesforce. As we write this, that deal has not closed and is awaiting regulatory approval. We are not printing a close date or a price, because neither is settled and both would age badly. We raise it for one reason: when you rent a platform rather than own it, who owns the platform is part of your diligence.
Contentful has said its API-first architecture and enterprise support will continue through the transition, with its direction being to enhance Salesforce's headless offering rather than replace what you build. Read that as a signal of enterprise gravity, not as a guarantee and not as a reason for alarm - it is Contentful's stated position on a deal that is not yet final, and a team choosing a long-term content backend should weigh it with open eyes. Salesforce does not own Contentful today, and no one should plan as if it does until the deal closes.
Whatever the ownership badge above the platform, the honesty below it does not change: your content and content model stay portable and yours, exportable through the API and the CLI, and the running service stays rented. That is exactly why we make the platform call on genuine fit at genuine scale - the axis this whole page is about - rather than on who signed what this quarter.
What a Contentful build costs
No quote wall. A Contentful build - the content model, the governance setup, the delivery, and a Next.js or Astro front end - is priced by our published web tiers, the same numbers as everywhere else. You always see the price before you commit.
Starter
1 week
A single-page site or landing page, live fast
Launch Sprint
2-3 weeks
Startups needing a fast, credible site
Growth Site
3-5 weeks
SMBs that want a lead engine
Commerce Sprint
4-6 weeks
DTC / e-commerce brands
MVP Sprint
6-10 weeks
Pre-seed / seed founders
How a Contentful build maps to these numbers
A content or marketing site on Contentful with a Next.js or Astro front end maps to the Starter, Launch or Growth tier by scope; a larger multi-team platform, deeper governance, or a migration onto Contentful is scoped as part of our web design and development service. One honest note on cost: our fee is for the build. The Contentful platform is a hosted service billed by Contentful directly, on their own plan - a genuine free tier to explore and paid plans that scale by spaces, users, locales and usage - and you pay Contentful directly for it; we take no markup. We help you read the plans up front so there are no surprises.
See full package details on pricing and our web development service.
Contentful development, answered
What is Contentful, and what is a composable content platform?
Contentful is an API-first, hosted headless CMS: it stores and serves your content over APIs but does not render your website. It calls itself a composable content platform because it is built for content assembled and orchestrated across many teams, brands, locales and channels at once - structured content types served over purpose-built APIs, with environments, roles, releases and orchestration to govern who publishes what, where and when. Below that scale it is a lot of platform; at that scale it is the coordination layer a large content operation runs on.
Is Contentful worth it, or is it too expensive?
It depends entirely on scale, and we answer by fit rather than defend the platform. Contentful earns its price when content is a coordination problem - many teams, brands, locales and channels shipping at once, needing governed environments, review and orchestration. If your content is one small team writing for one site, that governance is weight without payoff, and a leaner CMS is the honest, cheaper call. We would rather tell you it is more than you need than sell you the biggest tool in the shed.
Is Contentful still a good choice after the Salesforce acquisition?
Contentful has agreed to be acquired by Salesforce, announced in mid-2026 as a signed definitive agreement. As things stand that deal has not closed and is awaiting regulatory approval, so Salesforce does not own Contentful today, and we would not plan as if it did until the deal closes. Contentful has said its API-first architecture and enterprise support will continue. It is a fair thing for a long-term buyer to weigh, which is exactly why we make the platform call on genuine fit rather than on this quarter's headlines - and either way your content stays exportable and yours.
Is Contentful the right headless CMS for me, or is a leaner one enough?
It comes down to how much content governance you actually need. Contentful is the enterprise end of the structured, headless family: strong when many teams coordinate across brands and channels. A leaner, developer-first option like Sanity fits when content is structured but the team is small; Strapi fits when you want to own and self-host the running software; and WordPress fits when a team just wants to edit whole pages in a familiar admin. We are not a Contentful partner and have no incentive to push it, so if a leaner tool fits you better, we will say so.
Do I own my content on Contentful, and am I locked in?
You own your content and your content model - the type definitions, entries, assets and relationships - and you can export them at any time through the Content Management API or the CLI; the front-end code we write is yours too. What you do not own is the running platform: Contentful is a hosted service you rent and pay for directly. So the honest answer is not a flat 'no lock-in' - moving off any hosted platform is real work - but your content is exportable, structured data rather than a database held hostage, which is a very different risk than a closed page builder you cannot leave.
Can you migrate my existing site onto Contentful?
Yes, and it is a defined engineering sequence rather than a copy-paste. We model the target content types first, script the extract and transform from your current source through the Management API, and run the whole import into a non-production environment where we verify counts, references and rendered output before anything touches production. URLs are mapped and redirects planned before cutover, so your SEO equity and inbound links survive the move. Doing it in an isolated environment first is exactly what Contentful's environments are for.
Is Contentful good for SEO?
Contentful itself renders nothing, so SEO is a property of the front end you put in front of it. Pairing Contentful with a fast Next.js front end (for app- or SEO-critical sites) or Astro (for content sites) gives you server-rendered, fast-loading pages with full control of metadata and structured data. On a migration we protect SEO by mapping every URL, preserving metadata and setting redirects before cutover. We claim the method, never a ranking outcome.
Do you build the front end too, or just the Contentful backend?
Both. Contentful is the content backend; the website is a separate front end that reads it, and we build that front end on Next.js for app-grade and SEO-critical sites or Astro for content sites, reading Contentful over its Delivery or GraphQL API with preview builds and on-demand revalidation. Contentful models, governs and stores the content; the front end renders it. We deliver the whole path, and you own the front-end code.
Are you a Contentful Solution Partner, or Contentful certified?
No, and we will not imply otherwise. Contentful runs a Solution Partner program with a public partner directory, and we are not a Contentful Solution Partner and are not listed in that directory - you can check it. There is also no company-level or agency-level Contentful certification to hold: Contentful's certifications are individual credentials a person earns, issued as verified-skill badges, not a badge a company carries, so claiming a company certification would be a category error. We hold no SOC 2 report and no ISO 27001 certification, and there is no HIPAA certification for anyone to hold; any attestations belong to Contentful the platform, never to us.
Does this website run on Contentful?
No, and it shouldn't. This site is a static Next.js and React build, and its content is one small team's - a handful of pages, one release at a time. That is exactly the case where Contentful's enterprise governance would be overkill, so we would steer ourselves away from it, the same call we would make for you. Our own blog, guides and glossary run on a leaner CMS, Sanity, not Contentful, so Contentful is a permanent zero on our own domain - not for lack of capability, but because it would not fit.
Ready to build on Contentful - or find out it's more than you need?
Get a fixed-price quote for a Contentful build - the content model, the governance, and a fast Next.js or Astro front end that reads it, with content you own and can export. And if your content is really a single team's job, we'll tell you a leaner CMS fits you better first.