This blog is a folder of MDX files in our git repository, server-rendered to static HTML. There is no database behind it and no client-side rendering of article content. Every post ships the way our code ships: as a file, through a pull request, reviewed before it merges.
That choice is not minimalism for its own sake. We sell verification. Rival agents compete on a task, a blind cross-vendor jury checks the result criterion by criterion, and the customer merges one final with a Receipt. A company with that pitch should not publish its own words through a side door. The blog runs on the same trust machinery as the code.
Files beat a database for this job
A post here is a text file with a history. Diffs show exactly what changed between versions. Rollback is a git revert. Search is grep. The rendered output is static HTML, so there is no query to fail at read time and nothing for a reader's browser to assemble. The article you read is the artifact we committed.
This also matters for agents. Our tooling edits blog content with the same tools it uses on source code, in the same worktrees, under the same permissions. A separate content system would mean a separate integration, separate credentials, and a separate way to make mistakes.
Review is the publishing pipeline
Every post is a pull request. It gets a reviewer, a diff, and an approval before it merges, exactly like a code change. We sell a harness whose premise is that nothing ships on one agent's say-so, so it would be strange if our own writing shipped that way. For a company that sells verification, publishing through review is the point.
A claim that skipped review is just a draft with a URL.
The review checks structure as well as substance. Every entry opens with the verdict, because we write everything answer-first, and a post that buries its conclusion gets sent back the same way a vague commit does.
Frontmatter that is already a schema
Each file carries the same fields a CMS collection would: title, slug, description, author, publishedAt, updatedAt, tags, draft. We shaped the frontmatter like the collection we expect to have, not like the file format we happen to use today.
| today | after a CMS | |
|---|---|---|
| storage | MDX files in the repo | CMS collection |
| schema | frontmatter keys | the same keys |
| publishing | pull request | still reviewed |
| migration | not needed | an import script |
When a CMS arrives, migration is a script that reads these files and writes records. Not a rewrite, not a re-tagging project, not a month of copy-paste.
One host, readable by everything
The blog lives at fusioncoding.ai/blog, a subpath rather than a subdomain. That keeps topical authority, canonical URLs, and crawl signals on one host instead of splitting them across two.
And because many of our future readers are not people, the site ships a sitemap, RSS and Atom feeds, JSON-LD, /llms.txt, and /agents.md. It is the same principle as our headers-first docs: a machine should be able to route through our content from a declared map, not from scraping guesswork.
Where this goes
The stack will change; the gate will not. If we adopt a CMS, the import script carries the frontmatter across and the review requirement comes with it. Longer term, we want a published post to look the way a merged final looks today: reviewed, diffed, and traceable to the exact change that produced it. A blog is a small place to practice that discipline, which is exactly why we started here.