Executive Summary
The problem: Our marketing site ran on an off-the-shelf, drag-and-drop CMS. It was fine for templated content, but anything custom - a new layout, a navigation change, real interaction - had to go through a developer and could sit for a week or more. The same drag-and-drop markup left the site hard for search engines and LLMs to read.
Our solution: Rather than move to another CMS, we migrated the site into a code repository, using an autonomous agent loop to rebuild each page as clean Next.js and React. Pages are HTML now, with a clean Markdown version of each one kept alongside, and an AI coding agent is the editing layer. A conversational-git skill and enforcement hooks let the whole team build and publish without learning git. Every change gets an automated preview deploy on Cloudflare that anyone can open and check before it goes live.
The results: New pages that used to take a week now ship the same day. Designers build site-wide features end to end, from case-study filtering to animated homepage interactions, with no developer in the loop. Around 85 pull requests shipped in the first month, where we used to manage roughly one new post a week. After re-auditing, the site reads cleanly to AI and search. We also control the whole technical layer now - meta tags, markup, and structured data - which the CMS kept out of our hands.
What this article covers: Why we left the CMS behind entirely instead of replacing it, how we migrated with Claude, what we built so non-developers can work in the repository safely, what got faster and more discoverable, and what got harder.
Table of Contents
1. How Often Does Content Follow a Template?
A CMS is supposed to remove the developer from publishing. In principle, ours did. Content that fit an existing template could be published without engineering.
But our pages rarely fit the templates. Almost every one needed custom components - a specific layout, an interactive element, a piece of motion - and the CMS couldn't produce them. Our options were to hand-build each component in code, or subscribe to expensive, confusing add-on tools that promised to fill the gap. Neither was fast.
Real interaction polish - hover states, entrance animations, motion of any kind - either didn't work at all or took so long it wasn't worth it. The navigation, header, and footer were effectively hard-coded and out of the CMS's reach.
So every meaningful change went via a developer, and a new page could sit for a week or more, waiting on developer availability and the usual back-and-forth between design and engineering.
2. Slow to Publish, Hard to Find
We had two problems, and both needed solving. This was our third iteration of the site in 6 years as the company and the needs of the site have evolved.
The first thing we wanted was speed and freedom. Publishing anything beyond a template was slow and dependent on developers. The constraint was structural to the CMS, not the content itself, and it capped how ambitious we could be with the site.
The second was discoverability. The site was hard for LLMs and search engines to read. Part of that was the CMS itself: to power its drag-and-drop editing, it wrapped content in deep, nested markup, leaving a low ratio of real text to page code, exactly the kind of thing SEO and AI tools flag. As buyers increasingly research vendors through ChatGPT, Perplexity, Claude, and AI-powered search, a site they parse poorly is a red flag.
Our goals were clear: move faster, give the team more creative freedom, and become genuinely discoverable to AI and search.
3. Build Instead of Buy
We didn't want to trade one CMS for another. Given what is now possible with Claude, we weren't going to accept a new tool that would constrain us in some new way.
With Claude doing the heavy lifting, we pointed an autonomous Claude loop at the live site: reading each page through a browser, rebuilding each one as clean Next.js and React code against our coding standards, and reviewing its own output as it went.
Despite a messy starting point, what came back was surprisingly close to the live site. The old site was a real mishmash - some of it native to the CMS, some custom code, some hand-built first and migrated in later. For the loop to reproduce that as accurately as it did saved us from a ground-up redesign.
It wasn't perfect, responsiveness across breakpoints was the weak spot, and our developers spent time tightening it by hand alongside some data and metadata mistakes. A good lesson in doing a full QA on all AI work.
The migration took roughly three days and then a week and a half of polish before go-live. The new setup is simple: Markdown content in the repository, agent development kits as the editing layer, and agents and hooks in the loop.
4. Everyone Can Create
This approach is only useful to the team if it stops being a place only engineers can operate. Here's how we solve for that:
- Agent development kits. The team uses whichever coding agent they prefer - Claude Code, Codex, Cursor - so none of this is locked to one tool. We've packaged the helpers below as Claude Code skills and hooks, but the approach works across different agents.
- Conversational git. We built a skill that hides git behind plain English. You paste a single prompt to get set up, then work in sentences: "Share this with the team", "let me see the latest version". It handles branches, commits, and pull requests underneath. Contributors aren't expected to know git.
- One-command sharing and deployment. When you ask to share your work, it commits, opens a pull request, and Cloudflare ships a dedicated preview link in about two minutes. Reviewers see the change side by side with the current site before anything goes live. Dropping an image into a page uploads it to our Cloudflare storage automatically, so assets work out of the box.
- DESIGN.md. Our design language - components, naming, do's and don'ts - written as Markdown. Every agent reads this before touching the UI, so new work stays consistent with what already exists.
- Enforcement hooks. Automated checks flag duplicate components and style drift, and prompt you to pull the latest changes before you start. A backstop to the DESIGN.md.
- Markdown as the source of truth. A pre-commit hook keeps a clean Markdown version of every page, so there's never a question of which file is canonical, and the content stays in a form both people and models read easily.
5. Publishing Speed and Who Can Ship
New pages that used to take a week or more now ship the same day, as soon as the copy is ready.
More importantly, designers now build things that used to require a developer. Case-study filtering and sorting: the tags, the taxonomy, how studies appear on the tiles and on the page. That touches a large number of components and carries real logic, and a designer defined and built all of it end to end. So did the new homepage process diagram, with its animated glow and its collapse into a scrollable carousel, interaction that couldn't have existed in the old site. Navigation, dropdown styling, and motion, all previously off-limits, are now editable by the team. Around 85 pull requests have shipped in the month since launch. We used to be happy with a new post each week.
We've started automating the busywork around publishing, too. One hook fires when you add a new blog post: if the blog fits certain criteria, the hook suggests featuring the post on the homepage and opens the pull request for you to review. It sits somewhere between automation and AI assistance.
It also collapses the old pipeline. Before, designers prototyped with Figma & Claude, then handed off to engineers who rebuilt the custom components - two passes at the same work. Now the prototype is the real site: you iterate against the actual components and preview live in minutes. That is where AI prototyping is strongest, built against your real design system rather than a blank canvas, so you preview a page in-situ, not in a Google Doc.
6. Discoverability for AI and Search
When we audited the old site, it scored badly, in part because of the CMS, with its heavy markup and dropped metadata.
On the migrated version we fixed those issues, then re-audited in two ways: with the usual tooling, and by prompting LLMs directly to see what they could and couldn't read back. That surfaced one last configuration problem which was quickly fixed.
Clean Markdown rendered into lean, semantic HTML is what AI systems extract and cite accurately, and it's easier to keep correct over time. Because the team can now publish without a developer, we can also ship more of the content that drives discovery. Faster publishing and cleaner, well-structured pages compound.
7. Responsibility Shift
The biggest shift is accountability. On a CMS, you largely can't break anything. In our repository, you own what the agent writes for you. You still can't break the live site, everything is reviewed before it ships, but a loosely worded prompt can change more than you intended. Ask to "make this testimonial bigger" and you may have just changed a shared component across every case study. Knowing the difference between editing one page and editing the system behind it is a real habit to build.
More people editing means more pull requests, more stale work, and more conflicts. Some PRs sit for a couple of weeks and pick up conflicts in the meantime, so we now sweep the backlog every Friday. Claude's "helpful" suggestions occasionally need reining in too; it will volunteer changes you didn't ask for. None of this is unique to our setup, it's the cost of trading a gatekeeper for broad access, and it's one we'll take for the speed we get back.
8. The Obvious Fix Wasn't the Right One
The obvious fix and the right one aren't always the same. We could have got a new tool, but the constraint was never really the tool, it was the handoff the tool forced. Naming the actual constraint rather than the obvious one is most of the value in any modernization decision.
We treat the site as a living product now: publishing more often, tuning it continuously for AI and search discoverability, rather than relaunching it every few years.