The old setup was familiar: a headless CMS, a preview environment, fields for title and slug and SEO, a rich text editor that almost respected my markup, and a deploy pipeline that waited on a webhook like a nervous intern.

It worked. Until it didn't feel like writing anymore.

Every post meant logging into another UI. Drafts lived somewhere my editor extensions didn't. Diffs were awkward. “Who changed this sentence?” meant clicking through a revision panel that felt bolted on. Images had their own upload dance, then another dance to make sure the CDN and the build agreed. Local preview of the real page meant hoping the CMS sync behaved and that my laptop's notion of “draft” matched production's.

I'm a developer. My brain already lives in a repo. Fighting that for blog posts started to feel like renting a second office across town when I already had a desk.

There was also a subtle tax: the content model. Every essay had to fit the same shape — sections as JSON, fields as constraints, structure as schema. Fine for a newsroom. Weird for a founder who wants one post to be a long rant and another to be a walkthrough with a table of contents.

So I moved content into the codebase. Posts became pages. Copy lived next to layout. Hero images sat in public/. Publish meant merge and deploy — the same path the rest of the site already used. Open Graph images stopped being a separate content type and became files next to the article they belonged to.

The first week felt weirdly naked. No admin chrome. No “content model.” Just files. A little voice asked if I'd made things harder on purpose.

Then it felt obvious.

What Git gave me that the CMS didn't

Midway through the migration I wrote this down so I wouldn't romanticize it later:

• Real history — every edit is a commit I can blame, revert, or cherry-pick.
• Real review — PRs for posts the same way as code.
• Real local workflow — write in the editor I already use; preview with the real Next.js app.
• One deploy story — no CMS outage, no sync drift, no “content is live but build failed.”
• Portability — the content isn't trapped in a vendor's schema.

That list isn't universal truth. It's what mattered for a founder writing essays on a marketing site. Your constraints might be different. That's the point — choose the tool that matches who edits and how often.

Technically, nothing mystical happened. Markdown or JSX in a repo is an old pattern. Static sites did this for years. I just stopped pretending I needed a CMS because “blogs are supposed to have CMSs.”

👉 If your CMS is mostly a text box with login friction, you might be renting complexity you don't need.

The trade-offs I accepted

Non-developers can't casually edit posts. That's fine here — I'm the writer. If this were a magazine with ten contributors and an editorial calendar, I'd think twice. Maybe three times. A CMS earns its keep when the editors aren't engineers.

Scheduling is less “click publish at 9am” and more “merge when ready” or wire a tiny cron. Image pipelines need a little discipline so public/ doesn't become a junk drawer of half-compressed PNGs. SEO fields live in the page's metadata export instead of a CMS sidebar — which means I have to remember them, which I prefer to forgetting them in a UI I rarely open.

And yes, JSX-as-essay is more friction than Markdown in a CMS for some people. For me it's a feature: each post can be handcrafted. Layout can vary. I'm not stuffing every article into the same section schema because the schema made the admin happy.

That last point is why this site looks the way it does. Posts aren't rows in a database. They're pages with opinions about structure — some with a table of contents, some that just talk until they're done.

When a CMS still wins

If marketing needs to publish without engineering, use a CMS. If you have localization workflows, role-based approvals, or a content team that should never open a terminal — use a CMS. If your product is content at scale, you probably need one, and arguing otherwise is ideology.

Git won for this blog because the “CMS features” I was paying for — with money or cognitive load — were features Git already ships: history, branching, review, rollback, collaboration. The CMS was an extra database and an extra UI between me and shipping the next essay.

I didn't remove a CMS to be trendy. I removed it because the admin UI was standing between me and the work. Now the blog is just another part of the app. Commit. Push. Live.

That's enough. For this site, it was always enough — I just needed permission to admit it.