The Question Everyone Keeps Asking Me
Ever since I shipped this portfolio, the same question keeps coming up in conversations: if you built your website with AI, how do you actually update the content later? Are you just going to run Claude Code every time you want to publish a new article?
It's a fair question, and honestly, it's one I had myself when I started. For a while the answer was, well, yes. Every typo fix, every new case study, every article meant opening up the agent, asking it to edit a TypeScript file, committing, and waiting for Vercel to redeploy. That works, but it's not how a portfolio should feel. A portfolio is supposed to be a living thing, you should be able to write a paragraph from your phone on the bus and have it live ten minutes later.
So I went looking for a way to decouple the building of the site from the content on it. This article is about what I landed on, and why.
The Real Problem with AI-Built Sites
The problem isn't that AI agents are bad at editing files. They're great at it. The problem is that treating an agent as your CMS has a few practical downsides:
- Every content change is a code change. A typo fix becomes a commit, a PR, and a redeploy. That's a lot of ceremony for fixing a missing comma.
- You can't write from anywhere. If you're on your phone or someone else's laptop, you're locked out. The barrier to publishing goes up, and you publish less as a result.
- Non-technical collaborators are stuck. If you ever want a colleague, an editor, or a client to update their own content, asking them to spin up a coding agent isn't going to fly.
- The agent is a cost layer. Even small text edits burn tokens. Over a year, the difference between "run an agent" and "open a CMS" adds up.
The agent should be for building features, not for fixing typos.
Why I Picked Sanity
I looked at a few options before settling. The two main contenders were Notion (because everyone already uses it) and Sanity (which I'd seen come up in a few Next.js threads).
Notion is tempting because the editor is excellent and you're probably already in there every day. But the API has real limitations once you start using it as a CMS:
- Strict rate limits on the public API (around 3 requests per second per integration)
- No proper CDN, every fetch goes back to Notion's servers
- Page-as-database means content modelling is awkward beyond simple lists
- No built-in image transformations, so you're stuck with whatever you uploaded
For a low-traffic personal site you can absolutely get away with it. But if you ever get a spike, an article gets shared, you're linked from a newsletter, you're one rate limit away from a broken page.
Sanity approaches it from the other direction. It's a headless CMS built specifically for this use case:
- Content is served from a global CDN, so reads are fast wherever your visitors are
- The free tier is genuinely generous, well into the range a small site or freelancer will ever need
- Structured schemas mean your content has a defined shape you control
- Built-in image pipeline (resize, crop, format conversion) that plays well with Next.js's
- An embeddable Studio you can host on your own domain at a route like
/sanitystudio
The schema-driven approach is what sealed it for me. I can define exactly what fields an article has - title, slug, cover image, markdown body, keywords, and the Studio renders the right editor for each one. No fighting with a generic page builder.
What Changed in Practice
Once I migrated the articles over, the workflow flipped completely.
Before: Open Claude Code → describe the article → review the file diff → commit → push → wait for Vercel → check production.
After: Open /sanitystudio on any device → write in the markdown editor → hit Publish → it's live within an hour (or instantly if I bust the ISR cache).
The AI agent went back to doing what it's good at: shipping features, fixing bugs, refactoring components. The content layer became something I can touch from any browser, with no terminal in sight.
A couple of practical benefits I didn't anticipate:
- Drafts are real now. I can write half an article, save it, come back tomorrow. Before, half-finished content lived as a commented-out template literal in a TypeScript file. Not ideal.
- Images stopped being a chore. I drop a cover image into Sanity and it gets a CDN URL with hotspot data. Next.js handles the rest.
- The site builds faster. Articles are no longer compiled into the bundle as static data — they're fetched at request time (with ISR caching), so adding the tenth or hundredth article doesn't bloat the JS payload.
The Trade-Offs Worth Knowing About
I want to be honest about what you're trading away when you go this route, because no choice is free.
You add a dependency. Sanity is a service, and if it goes down, your CMS goes down. In practice their uptime is excellent and the CDN keeps published content available even during Studio outages, but it's still a vendor you didn't have before.
There's a learning curve to schemas. Defining your content shape upfront is more thought than "just write a Notion page". For one article type that's trivial, but if you have case studies, services, testimonials and articles you need to model each one.
The free tier has limits. Specifically: API requests, bandwidth, and number of users on the Studio. For a personal portfolio you'll likely never come close. For a client site you might want to plan for the paid tier eventually.
ISR caching can confuse you the first time. If you publish an update and don't see it immediately, that's not a bug, it's the Next.js data cache holding the old version until the revalidation window passes. You can force-bust it or just wait.
For my use case, a portfolio that needs to feel current without me opening a terminal, every one of these trade-offs was worth it.
The Bigger Point
The lesson I took from this isn't really about Sanity specifically. It's that the "AI builds your website" story leaves a gap, and the gap is content management. The agent ships the structure beautifully. It does not want to be your everyday publishing tool.
If you're building anything with Claude Code, Codex, or any other agent, decide early where your content is going to live. Treat the CMS as a first-class architectural decision, not something you'll figure out later. "Later" is when you have ten articles hardcoded into a TypeScript file and the prospect of moving them all feels miserable.
Pick the lightest CMS that fits your shape - Sanity, Contentful, Payload, Notion if you really must, and wire it in from day one. Your future self, sitting on a train trying to fix a typo from their phone, will thank you.
