Contentful to code you own.

[ Why teams move ]

The content is yours. Most of the bill is for everything around it.

Contentful solves a real problem: one content model, many surfaces, an API an engineering team can build against. Companies that chose it for that reason usually chose correctly.

What tends to change is the fit. Pricing is shaped around seats, spaces and environments, so the bill grows as more of the team gets near the content. The model that was right at the start becomes the hardest thing to change, because everything downstream depends on it. And the site itself is a separate front end that only developers deploy. And now a newer one: your team works with AI every day, and its agent can reach the content but not the site around it.

[ Is it time? ]

Three signs your site has outgrown Contentful.

Your team uses AI every day, for everything except the website.
Changes queue behind the one person who knows how the site is wired.
You’re paying a content platform’s price to put words on one website.

And it’s right to keep Contentful if you publish to several surfaces at once: a site, an app, a partner feed. That API is doing real work, and only the front end moves. We’ll tell you which on the Discovery call, with the evidence from your own site.

[ The path ]

From Contentful to an agentic website, in six steps.

Step 1

Map your Contentful site.

Discovery reads both halves: the content types, entries, references and locales in your space, including the fields nothing renders any more, and the front end that consumes them. You leave with a roadmap that says what moves, what it becomes, and in what order, including whether Contentful stays.
Step 2

Rebuild the front end as a system.

The front end is rebuilt as a component library on Astro, each component matched to the content type it renders, with your brand rules written into a brand.md. A site already built around an API is halfway to this shape.
Step 3

Decide where the content lives.

There are two honest options. Keep Contentful: the new site reads from the same space and your editors change nothing. Or fold the content into the repository: entries and assets are exported, references are resolved rather than left as links, assets are moved off the CDN you’re leaving, and localised fields come across where you use them. Discovery makes the call with you.
Step 4

Add the rails and the machine layer.

The guardrails and skills your agent will run on go in: what it may touch, how a page gets built, what gets checked before anything ships. The content model is tidied on the way, so the machine layer, structured data, schemas, llms.txt and a clean sitemap, is generated from fields that are actually in use.
Step 5

Switch over, with a net.

The redirects go live with the switch. If the content is moving too, the space keeps running for as long as you want afterwards. The renewal date is a sensible deadline. Cutover day isn’t.
Step 6

Take the keys.

Your team connects the agent it already uses and ships its first supervised changes in the first week of handover: a real page, a real edit, with us in the room. Someone who never had a seat can now brief a change and approve it.

[ Piece by piece ]

What each part of your Contentful site becomes.

	On Contentful	On an agentic website
[ 01/ Front end ]	A separate app that developers deploy	A component library in your repository, with a brand.md your agent builds against
[ 02/ Content ]	Entries in a Contentful space	Kept in Contentful, or content files in your repository. Your choice
[ 03/ Content model ]	Content types that are hard to change once live	Shapes kept with the site, where your agent can extend them
[ 04/ Assets ]	Images served from Contentful’s CDN	Moved across and served from your own site, if the content moves
[ 05/ Environments ]	Sandboxes to keep in step	A preview for every change, straight from the repository
[ 06/ URLs and rankings ]	URLs someone designed on purpose	Every URL redirected, metadata carried over, rankings watched through cutover
[ 07/ Making a change ]	A content type change, a migration script and a deploy	Brief the agent, check the preview, approve it
[ 08/ Adding a teammate ]	Another seat on the plan	No seats to change the site
[ 09/ When something goes wrong ]	Find out whether it was the entry, the model or the front end	A broken layout fails before it ships, and any change can be undone

[ The agent layer ]

On Contentful, your agent manages the entries. It can’t reach the site around them.

Contentful has an official MCP server and AI actions, so an agent can create and update entries, manage assets and work with content types. That’s the content half. The front end is a separate codebase the agent isn’t connected to, so a new section, a layout change or a new page type still goes to a developer.

On an agentic website the site is plain, structured files in your repository, so the agent your team already uses, Claude, Claude Code, ChatGPT, Gemini, Cursor, Codex, reads all of it and changes any of it. It builds inside your encoded brand and our rails, and the change arrives on a preview. The AI proposes, you approve what ships. A new campaign page becomes a brief, not a ticket, and adding ten marketers doesn’t add to the cost of shipping.

[ Where you land ]

An agentic website: yours, and run by your team.

The keys.

Code and content in your GitHub repository, under your name, from the first commit.
Your agent ships it.

Your team briefs the change in plain language and it lands on a preview. The AI proposes, you approve what ships.
Your brand, encoded.

A brand.md in the codebase, so every change, from anyone, is made against your rules.
Our standards, baked into the rails.

More than a decade of design and development standards, checked before anything ships.
The machine layer.

Structured data, schemas, llms.txt and a clean sitemap, so the AI systems answering your buyers can read and cite your site.
The handover.

Playbooks and paired working, until your team runs the site themselves.

[ Recent work ]

Built for SaaS teams like yours.

Autohive: a website that keeps pace with their marketing teamAn AI-agent company's first website, built on a component framework their designers, marketers and agents could all work in, so their marketing team builds its own landing pages and updates without waiting on anyone.Read more
Future of Marketing Work: a brand and website for a three-way eventAn Auckland event on how marketers adapt to digital transformation and AI, brought together by a university, the AI community and an events group. We made the brand, the website and the print.Read more
Landlord Studio: one system for two markets, run by their marketing teamProperty management software for landlords in the US and UK. A five-year-old Webflow build redesigned, migrated onto a component-driven framework, and handed to a marketing team that now builds its own pages with AI.Read more

Will we lose our rankings moving off Contentful?

A migration is built to keep them. Every live URL is mapped to its destination before anything moves, metadata travels with it, and rankings are watched through cutover so anything that shifts is caught and fixed. A headless site’s URLs were usually designed rather than generated, so the map tends to be short and every rule deliberate.

How long does a Contentful migration take?

The roadmap sets the timeline. It depends on the number of templates more than the number of pages. What stays fixed is the cadence: something visible ships every fortnight, from the first fortnight, on a live preview.

What happens to our content types and entries?

If Contentful stays, nothing: the new site reads from the same space. If the content moves, entries and assets are exported and land as versioned files next to the code. Content types become the shape of those files, references are resolved rather than left as links, and localised fields come across where you use them.

Contentful has an MCP server and AI actions now. Isn’t that enough?

For managing entries it helps, and if you keep Contentful we connect it. The gap is the site. Those tools work on content; the front end that turns it into pages is a separate codebase they don’t touch. On an agentic website your agent works on both: the content and the site, in one place, with a preview before anything ships.

Can our team still make changes ourselves?

More than before. Anyone on your team describes the change in plain language, the same way they’d brief a designer. The agent builds it inside your encoded design rules and it arrives as a preview for someone to approve. Nobody writes code or opens a terminal, and nothing ships without a person saying yes.

What’s the alternative to Contentful for a marketing team?

The usual answers are another headless CMS such as Sanity or Strapi, or a site builder like Webflow. The first swaps one content platform for another and leaves the front-end queue in place; the second gives up the structure you built. The third option is to own it: the site as code in your own repository, with your team’s agent making the changes inside rules we set, and a person approving each one. That’s an agentic website , and a migration is how most teams get there.

Can we keep Contentful and still do this?

Yes, if it’s doing work beyond the website. The front end is rebuilt as an agentic website and reads from the same space, so your editors change nothing and your marketers brief the agent for everything else. If the website is the only thing Contentful feeds, folding the content into the repository is usually simpler.

Can we time the move around our renewal?

Yes, and it’s worth planning for. The front end can move first while Contentful keeps serving the content, and the content can follow before the renewal date. Tell us the date on the Discovery call and the roadmap is built around it.