Content As Code: The Business That Can See Itself

I had forty-five published insights and a problem. The writing was doing its job — the arguments were landing, the pieces were ranking, the voice was consistent. But the presentation was losing people before the writing had a chance. Walls of prose. No visual anchors. Nothing for a scan reader to stop on.

I’d built a brilliant formatting toolkit — six CSS classes. A standfirst that earns the scroll. A pull quote that stops it. A featured pull quote for the single strongest line. A stat block, an inline highlight, a callout box. Simple components, dropped into the markup.

The question was how to retrofit them across forty-five published pieces.

In WordPress, I know exactly what that looks like. I’ve done it. You open the post editor. Scroll past the Yoast box. Find the right paragraph. Paste the HTML. Preview. Update. Navigate back to the post list. Open the next one. Forty-five times. If you’re disciplined and you don’t check email between posts, that’s a full day. If you’re honest about how humans actually work, it’s two.

I’ve tried the shortcut too — phpMyAdmin, search and replace directly in the database. It works, technically. But you’re writing raw SQL against serialised content, one wrong query from breaking every post on the site, with no preview and no undo. Clunky doesn’t begin to cover it.

Claude Code did it in one pass. Every insight is a text file in a folder. It read each piece, found the strongest line, found the sentence that earns the scroll, wrote two divs into the markup, and moved to the next. Minutes, not hours. One commit. 138 lines added, 45 removed. The diff showed every change across the entire publication in a single view.

That’s content as code. Not a philosophy. Five minutes on a Tuesday afternoon.

The File Is the Page

Every insight on this site is a text file. Markdown with components. It sits in a folder, and when the site builds, each file becomes a page. No database. No content management system. No admin panel between the writing and the publishing.

The file is the page. Not a representation of it. Not a record that gets transformed into it. The file you write is the page you publish. List the folder and you know what’s on the site. Check the git history and you know what changed last week. Search the files and you find every mention of a phrase across the whole publication.

That sounds abstract until you’ve lived on both sides. I spent twenty-six years building WordPress sites. I know the admin panel. I know the post editor. I know the feeling of clicking through pages one at a time, each one a separate visit to a separate screen, each one requiring a login and a load and a scroll to the content you’re actually there to edit.

What I didn’t know — couldn’t know until I crossed over — was how much that friction was hiding from me. Not because WordPress is bad software. Because a database stores content in rows, and rows are invisible to everything except the application that reads them.

I have a client who’s been with me for fourteen years and has never touched a content management system. Not once. He doesn’t want to. He wants a website that works and someone who answers the phone. The CMS was never serving him. It was serving the assumption that he’d self-serve — and maintaining an admin panel, a database, a plugin ecosystem, and an authentication layer for a feature he never used. I removed the assumption and the infrastructure that served it.

What Becomes Possible

The prettify retrofit was one example. Here are two more.

The Internal Linking Pass

I ran a search across every insight file for outbound links. Every cross-reference, every related piece, every call to action. The search took seconds because the files are plain text.

I could see the full link graph in one view. Which pieces linked to which. Where the clusters were. Where the gaps were. Fourteen insights got new cross-links in one pass. One commit. The diff showed exactly which links were added and where. And because every change is a commit, the publication has a memory that doesn’t depend on mine — I can trace any link back to the day it was added and the reason it was there.

The Editorial Calendar

I don’t have a content calendar. I don’t have a Trello board of ideas. I don’t have a spreadsheet tracking what’s published, what’s in draft, what needs updating.

I have a folder.

Every file carries its own metadata: title, publication date, last updated, category, tags, draft status. The folder is the calendar. A command reads it and tells me what’s going stale, what topics are clustering, where the gaps are. Not from a dashboard — from the files themselves. The content intelligence is derived from the content, because the content is readable by the same tools that run the business.

The Kitchen Can See the Front of House

The system I’ve built — the wiki, the commands, the operational tools — reads the codebase. It reads the wiki. And because the insights are files in the same repository, it reads the publication too. The kitchen can see the front of house.

When I ask the system what content gaps exist, it doesn’t guess. It reads the folder, checks the metadata, looks at publication dates in the git history, and tells me what’s there and what isn’t. It knows I haven’t published anything about Shopify shipping since November. It knows the migration guides cluster together and there’s nothing linking them to the service page. It knows which pieces are approaching stale because it can see the dates in every file.

None of this is possible when content lives in a database. A WordPress site stores your posts behind an authentication layer, accessible only through the admin panel or the REST API. The system can’t walk into the restaurant and look around. It has to ask the waiter what’s on every table, one table at a time.

The Enabling Condition

The prettify toolkit, the internal linking pass, the editorial intelligence — none of these are clever features. They’re ordinary operations that become possible when you remove the wall between the content and the tools.

Content as code isn’t a developer workflow. It’s the enabling condition for a business that can see its own front of house from the kitchen. Every piece I write about the system, every observation about how corrections compound, every argument about why the infrastructure matters — they all depend on this one architectural decision.

The content lives in files. The files live in a repository. The repository is readable by everything.

If you want this kind of thinking applied to your business — here’s how I work with clients, or get in touch.

Related: The Atomic Commit · The Split Brain · The Tier System · Teaching Claude Code Taste · The Correction Loop