Strapi to code you own.

[ Why teams move ]

You own all of it already. It’s the seam that costs you.

Strapi teams are the closest to where this ends up, and it’s worth saying so plainly. You self-host, the code is yours, the content is yours, and there’s no vendor with an opinion about your roadmap. Almost everything we argue for, you already did.

What’s left is the seam. There’s a CMS server to run, patch and upgrade, a database behind it, an admin build that needs attention every major version, and a front end that talks to all of it over an API. None of it is difficult, but it’s permanent, and it’s work that produces no pages. 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 Strapi.

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 patching a CMS server for a handful of editors who’d rather describe a change.

And it’s fine to keep Strapi if a large team of editors relies on its admin: roles, permissions and a publishing workflow people use every day. Then the CMS is earning its place, 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 Strapi to an agentic website, in six steps.

Step 1

Map your Strapi site.

Discovery reads both halves: the content types, components and relations in your own schema, and the front end that renders them, its templates, its queries and how it’s deployed. You leave with a roadmap that says what moves, what it becomes, and in what order, including whether Strapi 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 it renders, with your brand rules written into a brand.md. A site already built against an API is most of the way there. What changes is that your agent can now work on it.
Step 3

Decide where the content lives.

There are two honest options. Keep Strapi as the editor: your content stays where it is and the new site reads from it, which suits a large editorial team. Or fold the content into the repository: entries are exported from your own database and become structured content files, with relations, media and draft states carried across. 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. Because your content is already structured, the machine layer can be done completely and quickly: structured data, schemas, llms.txt and a clean sitemap, generated from the same model.
Step 5

Switch over, with a net.

The redirects go live with the switch. A self-hosted site’s URLs were designed rather than generated, so the plan tends to be short. If the content is moving too, the Strapi server can keep running for as long as you like afterwards, and the day you switch it off is the one worth celebrating.
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. A new section or page type is a brief and a preview, rather than a schema change, a front-end ticket and a deploy.

[ Piece by piece ]

What each part of your Strapi site becomes.

	On Strapi	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 your Strapi database	Kept in Strapi as the editor, or content files in your repository. Your choice
[ 03/ Content model ]	Content types and components in Strapi’s schema	The same shapes, kept with the site, where your agent can extend them
[ 04/ Hosting ]	A CMS server, its database and a front-end host	One site, in an account under your name
[ 05/ Upkeep ]	Patches, upgrades and an admin rebuild every major version	Nothing to patch. If Strapi stays, it stays for the editors
[ 06/ URLs and rankings ]	URLs someone designed on purpose	Every URL redirected, metadata carried over, rankings watched through cutover
[ 07/ Making a change ]	A schema change, a front-end ticket and a deploy	Brief the agent, check the preview, approve it
[ 08/ When something goes wrong ]	Find out whether it was the server, the content or the front end	A broken layout fails before it ships, and any change can be undone

[ The agent layer ]

On Strapi, your agent can reach the content. It can’t reach the site around it.

Because you host Strapi, an agent can be given its content API and create and update entries, and that’s real help for content work. The front end is another matter: it’s 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, followed by a deploy.

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 Strapi?

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 self-hosted site’s URLs were designed rather than generated, so the map tends to be short and every rule deliberate.

How long does a Strapi 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 our Strapi server?

If Strapi stays, nothing: the new site reads from the same content API. If the content moves, content types become the shape of the files, and entries, relations, media and draft states are carried over as they are. The server keeps running for as long as you want, and then you switch it off: one process, one database and one upgrade cycle stop being yours to maintain.

We already own the code. Why move at all?

Because owning the code and running the site are different jobs. Today the code is yours but every change still needs a developer, a schema change or a deploy. On an agentic website your team’s agent can work on the whole site, content and front end together, with a preview before anything ships. You keep the ownership and lose the queue.

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 Strapi for a marketing team?

The usual answers are a hosted headless CMS such as Sanity or Contentful, or a site builder like Webflow. The first trades your self-hosting for someone else’s platform and leaves the front-end queue in place; the second gives up the structure you built. The third option is to own a simpler site: 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 Strapi and still do this?

Yes, and for a large editorial team it’s often the right answer. The front end is rebuilt as an agentic website and reads from the same Strapi content, so your editors change nothing and your marketers brief the agent for everything else. See Headless CMS websites .

Do the front end and the content have to move together?

No. The front end can move first while Strapi keeps serving the content, and the content can follow later, or never. Because you own both ends already, each step is reversible, and there’s no contract or export window setting the pace.