Run a company blog with no CMS — the files-in-repo pattern

Before building this blog we studied how fast-moving AI companies run theirs. The pattern at the engineering-led ones is remarkably consistent, and it is the opposite of what the marketing-stack industry sells: no CMS at all. Articles are files in the code repository. A build step renders them to static pages. The "editorial workflow" is a pull request.

This page you are reading works exactly that way, so consider this both a guide and a demonstration.

The pattern

• Content is files. Each article is one markdown file with a small frontmatter block: title, description, type, cluster, date. The repo is the archive, the history, and the backup — for free, forever.
• A build step, not a server. A short script renders markdown to HTML when the site is built. What gets served is static files: nothing to patch, nothing to breach, nothing that goes down under load.
• Templates over layouts. A handful of article types — explainer, comparison, strategy guide — each with a fixed shape. Constraint is what makes a library of a hundred articles feel like one publication instead of a hundred opinions.
• Clusters over categories. Articles group by the search intent they serve, and the index page is organized by cluster — which quietly makes your keyword strategy legible to crawlers and humans alike.

Why it beats a CMS for this job

A CMS earns its cost when many non-technical people edit concurrently and need roles, previews, and a friendly UI. A company blog written by a small team — or by agents — has none of those needs, and pays all of the costs: a service to host and upgrade, a database to secure, a plugin surface to worry about, and content that now lives outside version control.

Files in a repo invert every one of those. Review happens as a diff. History is git log. Rollback is git revert. And if your writers are agents, the repo is also where their gates already operate — in our case, nothing merges until the facts gate has checked every claim against the company's truth files and the quality gate has passed the piece as a whole. The workflow tool and the safety tool are the same tool.

When a CMS does earn its place

Honesty requires the other column. Reach for a real CMS when:

• Non-technical humans must edit directly — a client's marketing team that will never open an editor, let alone a repository.
• Content is data, not documents — thousands of structured records (products, listings) queried by many surfaces through an API.
• Legal workflow demands it — audit trails and approval chains that your organization insists must live in a UI.

Even then, the choice matters. Self-hosting an open-source CMS inside the account's own infrastructure keeps the content owned by the company rather than a third-party cloud — and publish hooks give you a place to enforce the same gates, so the CMS becomes governed by the system instead of a side door around it.

The uncomfortable summary

Most companies buy a CMS the way they buy a gym membership — for the person they imagine becoming. Start with files. You will know precisely when you have outgrown them, because the constraint will have a name and a face. Until that day, the simplest publishing system is the one that cannot break.