Your Code Already Is a CMS

I helped a friend set up Contentful for his 8-page marketing site last year. Four hours of configuration - content models for "Hero Section," "Feature Grid," and "Testimonial Carousel," plus webhook setup, preview environment configuration, API rate limits, and GraphQL queries to wire it all together.

His homepage has 340 words on it. We spent more time configuring the CMS than it would take to type those words out by hand, twice.

When I asked him why he needed a headless CMS, he looked at me like I'd asked something stupid. "So marketing can update content without bothering developers." Makes sense, except his marketing team is him - he's a solo founder. He was setting up a system to protect developers from himself.

Every CMS sells the same promise: "Separate content from code so non-technical people can make updates."

I've worked with teams using Contentful, Sanity, Strapi, Prismic, and half a dozen others. The workflow is always the same:

• Developer spends 2-3 days defining content models
• Developer builds frontend components that consume those models
• Developer configures preview environments (another day, minimum)
• Developer writes migration scripts when schemas change
• Developer debugs when the API returns unexpected data
• Developer troubleshoots when the webhook doesn't fire
• And then, finally, marketing can change a headline

The "separation" didn't remove developers from content changes. It multiplied the developer work required before anyone else could touch anything.

One team I talked to calculated they'd spent 180 hours over two years maintaining their Contentful integration. Schema migrations, API version upgrades, webhook debugging, preview environment fixes. They have 23 pages on their marketing site.

Git solved content versioning in 2005, but we didn't notice because we were too busy building databases.

Think about what you get for free with any Git repository:

• Complete history. Every character changed, who changed it, when, why. Not as a premium feature - as the fundamental data structure. Contentful charges extra for content versioning beyond 200 versions. Git has unlimited history by default.
• Branching and previews. Want to see changes before they go live? Make a branch. Vercel and Netlify will spin up a preview deployment automatically. No separate staging configuration.
• Review workflows. Pull requests with inline comments, threaded discussions, approval requirements, requested changes. Every major CMS has tried to build an approval workflow. None of them are as good as GitHub's PR reviews.
• Instant rollbacks. Something wrong? git revert abc123. Done. No digging through a CMS admin panel trying to figure out which version of which content type broke things.

The head of marketing needs to change "Start Free Trial" to "Get Started Free." She can't open VS Code, find the right component, edit the string, stage the change, write a commit message, and push to a branch. That's 8 steps and 4 tools she's never used.

So we built an alternative: a completely separate database to store that string, a completely separate admin interface to edit it, a completely separate API to fetch it, and a completely separate deployment pipeline to publish changes. A $50/month Contentful plan to change four words.

The content didn't need a database, an API, or webhooks - the editing interface needed to be simpler. We solved the wrong problem.

Large language models can read code. They understand JSX, understand that <h1>Welcome to Acme</h1> is a heading, understand that changing "Welcome to Acme" to "Welcome to Acme Corp" means modifying that specific string in that specific file.

This is new. Two years ago, building a visual editor that could modify arbitrary React components would have required months of parsing logic, AST manipulation, edge case handling. Now you can describe what you want changed, and AI generates the exact file diff.

• No schemas. Your React components already define the structure. A Hero component with title and subtitle props is a schema - AI can infer it.
• No API layer. Content is in files. No GraphQL queries. No REST endpoints. No rate limits.
• No sync bugs. There's one source of truth: your code. Not code + database + cache + CDN.
• No lock-in. It's text files in your repo. Switch tools tomorrow. The content doesn't move.

From the marketing person's perspective, nothing changes - they see a page, click on the text they want to edit, make their change, and hit save. It looks and feels like any other CMS. But behind the scenes, that generated a pull request with a one-line diff to the right file, using the same review workflow as any other code change.

What about large sites?

If you have 10,000 product pages updated by an automated feed, use a database - this approach isn't for you. But most marketing sites have 15-50 pages that get updated maybe once a week. The New York Times needs a CMS. Your SaaS landing page probably doesn't.

What about user-generated content?

Comments, forum posts, and user profiles are runtime data that belongs in a database because users create it at runtime. But your homepage copy, your about page, and your pricing table aren't user-generated - they're editorial content, and editorial content and user data are fundamentally different problems.

What about non-technical users?

They never see Git or touch code - they see a visual editor that looks like Notion or Google Docs where they can click, edit, and save. The system handles everything else: generating the diff, opening the PR, running checks, and deploying on merge.

A friend's company migrated off Contentful last year. Took them 11 weeks. They had 67 content types, 4 years of content history, 2,300 assets. The export was a 340MB JSON file that mapped to nothing in their new system.

They had to write custom scripts to transform every piece of content. Rich text fields used Contentful's proprietary format - had to convert to standard HTML. Asset references pointed to Contentful's CDN - had to download and re-upload everything. Linked entries used Contentful's internal IDs - had to rebuild all relationships.

Contentful didn't do anything wrong. Their data export worked fine. But the data model was Contentful's data model. Moving to a different system meant reverse-engineering four years of content structure decisions.

If their content had lived in their repo the whole time, there'd be nothing to migrate. Switching editing tools would be exactly that - switching tools. The content wouldn't move because it was already home.

Here's what a headless CMS adds to your stack:

Your App → GraphQL/REST → CMS API → CMS Database → CMS Admin UI
                ↓
        (webhooks, caching, CDN, preview APIs...)

Here's what a Git-based approach looks like:

Your App ← Files in Repo ← Visual Editor
                ↓
        (that's it)

Fewer services, fewer API calls, fewer things that can timeout or rate limit or return 500 errors at 2am. Your marketing site doesn't go down because Contentful's having an outage, because there's no Contentful in the request path.

Static site generators already proved this model works - Gatsby, Next.js, Astro, millions of sites built on the idea that content can live in files. The only piece missing was giving non-developers a way to edit those files without learning Git.

AI fills that gap. It translates "I want to change this headline" into the exact file edit needed, so the person editing sees a simple interface while the codebase receives a clean commit. The complexity doesn't go away - it just becomes invisible.

Your code already knows where your content lives, already has version control with branching and reviews and rollbacks, and already deploys automatically when you push. The only thing missing was making that accessible to everyone.

That's what we built.