Most blogs reach for a CMS on day one. We didn't. For a marketing-site blog that a handful of people write for, a content management system is infrastructure you have to run, secure, and pay for before you have published a single post.
The file-based approach
Instead, every post is an MDX file in the repository. Frontmatter carries the metadata; the body is Markdown with the option to drop in React components when a post needs something interactive.
The whole pipeline is a few small pieces:
gray-matterparses the frontmatter.- A
getAllPosts()helper reads thecontent/blogdirectory and powers the index, the sitemap, and per-post metadata from one source. next-mdx-remotecompiles each post at build time.
export function getAllPosts() {
return listPostFiles()
.map((file) => {
const { slug, frontmatter } = readPostFile(file);
return { slug, ...frontmatter };
})
.sort((a, b) => new Date(b.date) - new Date(a.date));
}Because posts are static, every page is pre-rendered. There is no database to back up, no admin login to protect, and content review happens in the same pull request as the code.
What you give up
This approach has real trade-offs, and they are worth naming honestly.
| CMS | File-based |
|---|---|
| Non-technical authors can publish without a developer | Authors need to be comfortable editing files and opening pull requests |
| Live preview before publishing | Publishing requires a rebuild and a deployment |
| Built-in image handling and media library | Images are managed manually in the repository |
| Scheduled publishing from a UI | Scheduling requires a CI/CD integration or a timed deploy |
For a team that lives in a code editor, these trade-offs are fine, possibly preferable. For a content or marketing team publishing independently on their own schedule, they become genuine blockers.
When we'd add a CMS
This trade-off holds while the people writing posts are comfortable editing files. The day a non-technical team needs to publish on their own schedule, a CMS earns its keep. The file-based layer we built makes that migration a content export, not a rewrite: the MDX files become the source for a headless CMS import, and the rendering layer stays the same.
Pick the simplest thing that solves today's problem without boxing in tomorrow's.
Until then, we will keep writing in the editor we already have open.
