Lee Robinson’s weekend project caught my attention because we’re wrestling with exactly this question while building Nua Site.
He migrated cursor.com from Sanity (a headless CMS) to “just code and Markdown” in 3 days. Cost: $260 in API tokens, 344 agent runs, 297M tokens. Result: simpler codebase, lower costs, and a site AI agents can actually work with.
Sanity fired back with “You should never build a CMS”, arguing that at scale you still need structured content and collaboration tools—and that Lee basically rebuilt a CMS using scripts and GitHub anyway.
They’re both right, which is the problem.
The real question for founders isn’t “CMS vs. no CMS.” It’s:
Given our team, our content needs, and where AI tooling is heading, what’s the simplest thing that could possibly work?
We’re building Nua to help with this transition, but I want to be clear: ditching your CMS is not always the right move. Here’s how to think through it honestly.
What Actually Happened
Lee’s migration was straightforward:
Before: Next.js + Sanity CMS handling pages, blog, and assets
After: Same site, but rendered from Markdown files in the repo, assets in object storage
The numbers:
- 3 days of work
- 344 agent requests
- ~297M tokens
- 67 commits
- Net deletion of hundreds of thousands of lines of code
But the “why” matters more than the “how”:
- CMS complexity was real: Auth, preview modes, localization, plugins, CDN billing
- AI agents couldn’t reach content: They could grep and edit code, but content stuck behind authenticated APIs was invisible
- Team structure fit it: Small, technical team where “designers are developers” and everyone lives in GitHub
In that specific context, the CMS wasn’t solving problems—it was creating them.
The Two Sides (and Why Both Make Sense)
The “Content as Code” camp
Includes Cursor, Prefect, indie devs, and framework authors (Astro, Nuxt Content, etc.)
Their argument:
- Content is just code—if it’s all in files, agents can grep, refactor, and ship changes end-to-end
- Abstractions are expensive in the agent era—every API boundary slows you down
- Git is a feature—version control unlocks CI/CD for content (linting, style checks, QA bots)
Prefect wrote about cutting their landing page turnaround from weeks to ~30 minutes by moving to Markdown + Git. That’s compelling if you’re a technical team.
The “Content Infrastructure” camp
Includes CMS vendors (obviously) and large content teams.
Their argument:
- You can delete the CMS, but not the problems it solves—asset management, permissions, scheduling, localization, multi-channel reuse all still need solving
- Git is not a collaboration tool for non-devs—merge conflicts, no real-time editing, branch-based workflows that don’t map to campaign work
- Structured content matters at scale—when pricing and legal copy appears everywhere, “Markdown + grep” becomes brittle
Sanity’s take: the right move is making the CMS agent-friendly (like their MCP-based toolkit), not throwing it away.
Here’s what I think: Both are correct for different situations. The mistake is assuming one approach fits everyone.
Who’s Actually Migrating (and Who Should)
Currently moving away from CMSes:
1. AI-native product companies (Cursor, Prefect)
- Comfortable with agent pipelines
- Already using GitHub as core infrastructure
- Small marketing teams close to engineering
- Treating content like code: CI/CD, automated checks, agent-driven updates
2. Indie devs and small agencies
- Migrating WordPress/Webflow sites to Next.js/Astro + Markdown
- Using Cursor to do the heavy lifting
- Designers who code, embracing “everything through Git”
3. Hybrid adopters
- Keeping CMS for structured, cross-channel content (product catalogs, legal copy)
- Moving “pure marketing” pages to file-based stacks
- Using agent tooling (MCP servers) to bridge both worlds
This hybrid is probably where most mid-sized companies land.
The Decision Framework (Be Honest with Yourself)
You’re probably ready to go CMS-less if:
Team profile:
- 3-20 people touching the marketing site
- Designers/marketers comfortable with modern tools (Figma, GitHub, Notion)
- Content surface is mostly marketing pages, docs, blog—not a multi-brand platform
- You value iteration speed over complex workflows like scheduled multi-locale campaigns
Workflow reality:
- Already using Cursor, Copilot, or similar tools daily
- “Ask Cursor to clone this landing page and adjust pricing” is realistic for your team
- Content changes start from product/dev, not a 40-person content department
What you’ll actually get:
- Lower complexity—no CMS auth, preview, plugin ecosystem to maintain
- Better agent leverage—agents see everything in one repo
- Simpler operations—static pages, cheaper hosting, fewer moving parts
Your options:
- DIY the migration (like Lee did)
- Use a tool like Nua to automate it
- Go with file-based frameworks from day one (Astro content collections, Nuxt Content, etc.)
You should probably keep your CMS if:
1. Large, non-technical content organization
- Dozens of editors, translators, legal reviewers, regional marketers
- Heavy need for draft states, approvals, scheduled publishing, embargoes, audit trails
Git branches and Markdown can technically handle this, but it’s painful. Merge conflicts in prose, no real-time editing, and branching models that don’t map to “campaigns” create real friction.
2. Complex, reusable structured content
- Product data reused across marketing pages, in-app UIs, docs, partner feeds
- Legal/compliance language that must be updated globally
- Multi-language content with intricate translation workflows
This is where schemas, references, and query languages (like GROQ in Sanity) earn their keep. Doing this with Markdown + grep pushes you into “building your own CMS” territory fast.
3. Multi-channel from day one
- Website is one of many channels (apps, storefronts, embedded widgets, PDFs)
- Need a central content store as system of record
In this case:
- Keep or modernize the CMS
- Make it agent-native (via MCP servers or similar)
- Maybe move simple “brochureware” pages to a file-based setup, but keep the CMS for structured content
Quick Decision Checklist by Company Stage
Early-stage SaaS (5-30 people)
- 1-3 engineers, maybe a designer who codes
- Founder or PM writes marketing copy
- Website: homepage, pricing, features, docs, blog
Recommendation: Seriously consider file-based + agents. Full headless CMS is rarely worth it at this stage.
How to do it:
- Build with Astro/Next.js from day one (if starting fresh)
- Use Cursor/Claude to migrate (if you already have a site)
- Try Nua if you want the migration automated (that’s what we’re building it for)
- Or just write Markdown files and deploy to Vercel/Netlify/Cloudflare
Growing B2B (30-200 people)
- Dedicated marketing and content teams
- Multiple regions/languages
- Website is central to pipeline generation
Recommendation: Don’t rip everything out. Go hybrid.
How to do it:
- Move simple content (blog, changelog, some landing pages) to Git/Markdown—make it agent-native
- Keep structured, cross-channel content in a CMS, but add agent access (e.g., Sanity’s MCP toolkit)
- Get agent speed where it matters without breaking editorial workflows
Content-heavy or media company
- Many writers and editors
- Multi-brand, multi-channel, complex rights and scheduling
- Possibly multiple CMSes already
Recommendation: Stick with a serious CMS.
Focus instead on:
- Cleaning schemas and reducing bespoke complexity
- Integrating AI agents via MCP so they help with generation, QA, migrations
- Moving only obvious wins (simple microsites, docs) to file-based stacks
A full Cursor-style migration probably isn’t worth it yet.
Where Nua Fits (and Where It Doesn’t)
I’m building Nua Site because I think there’s a gap between “DIY migration with 344 agent runs” and “stay locked in your CMS forever.”
What Nua does:
- Automatically migrates your existing site to a clean Astro + Tailwind codebase in your GitHub repo
- Makes content agent-native from day one (files, not APIs)
- Visual editor coming for non-technical teammates (click-to-edit, AI assistant)
- No lock-in—it’s just code you own, host anywhere
Who it’s for:
- Semi-technical teams feeling CMS friction but worried about abandoning non-technical colleagues
- Early/growth-stage companies wanting to move fast with AI tools
- Teams who want the Lee Robinson outcome without writing custom scripts
Who it’s NOT for:
- Large content organizations with complex editorial workflows (hybrid CMS + file-based is probably better)
- Multi-channel content operations where a headless CMS is genuinely earning its keep
- Teams who need the full power of structured content schemas and query languages
The Pattern I’m Seeing
The “post-Lee” conversation is settling into this:
-
Move your marketing surface to a file-based, agent-native stack (if your team can handle it)
-
Layer a lightweight visual/editor experience on top (for non-technical teammates)
-
Keep structured content in a CMS only where it truly pays for itself (product data, multi-channel, complex workflows)
That’s the direction things are heading. The CMS isn’t going away entirely—it’s shrinking to the use cases where it’s genuinely better than code.
The question is: where does your team sit on that spectrum?
Be honest about:
- Your team’s actual technical comfort
- Your content complexity and reuse patterns
- How much you’re willing to invest in tooling and workflows
- Whether your CMS is solving problems or creating them
Then pick the simplest thing that could work.
For us at Nua, that means making “step 1” (migrate to code) trivial and “step 2” (visual editing) comfortable, so you can decide calmly where you still need heavy infrastructure—and where you’re better off without it.
But if your answer is “we actually need a full CMS,” that’s fine. Use Sanity’s MCP toolkit or something similar. Make it agent-friendly. That’s a valid path.
The win isn’t “everyone ditches their CMS.” The win is choosing the right level of complexity for your actual needs.