Building a Typed MDX Content Engine for a Zero-Cost Blog
This is a sample post. Real, original write-ups are being cooked up right now, brewing slowly, but properly.
Building a Typed MDX Content Engine for a Zero-Cost Blog
This blog has no database. Every post is a Markdown file with frontmatter, read from disk at build time and rendered to static HTML.
Quick answer: posts live at
content/posts/{id}-{slug}/post.mdx, parsed withgray-matter, typed end-to-end, and cached in memory during the build so hundreds of files only get parsed once.
Why filesystem over a CMS
- Zero infrastructure cost — no database to provision or pay for.
- Content lives in git, so every edit is versioned and reviewable.
- Publishing is a
git push, which fits a fully automatable pipeline.
The folder convention
content/posts/001-what-is-rag-and-why-it-matters/post.mdx
content/posts/002-building-a-typed-mdx-content-engine/post.mdx
The numeric prefix keeps folders sortable on disk; the slug in frontmatter (if present) overrides the folder-derived slug for the actual URL.
Key Takeaways
- Static content loaders scale further than most people expect.
- Typing the frontmatter schema catches bad posts before they ship.
- A future-dated
publishedAtgives you free drip-release scheduling.
Frequently Asked Questions
Why not use a headless CMS? For a solo blog, git already is the CMS — with better diffing.
Related Reading
Related reading
Postgres for AI Apps: A Practical Primer
Why Postgres — with pgvector — is often the only database an AI app actually needs, and where it starts to strain.
Getting Started with Pydantic for LLM Outputs
Why raw text out of an LLM is a liability, and how Pydantic models turn it into something your code can actually trust.
What Is RAG, and Why It Matters
Retrieval-Augmented Generation in plain terms — what it actually does, when it's worth the added complexity, and when it isn't.