Architecture of my blog

I have a confession: I hate Content Management Systems.

For a personal engineering blog, they always feel like overkill. I don't want to log into a dashboard, navigate a rich text editor that mangles my code blocks, and wonder if the "Preview" button is lying to me.

I want to write code. I want my writing to live with my code. I want to git push my thoughts.

So, naturally, I over-engineered a solution. And soon, I'm releasing it so you can over-engineer your blog too.

The "Filesystem is the Database" Manifesto

The architecture here is deceptively simple, but it relies on a few key decisions that make it scream.

1. MDX is the Engine

We aren't just parsing Markdown. We're compiling MDX. This means every post is effectively a React component.

If I want to demo a button component right here, I don't need an iframe or a screenshot. I just import it.

import { Button } from '@/src/components/ui/Button';

<Button>Click me</Button>

This collapses the boundary between "content" and "application". The blog post is the app.

2. Zero-API Search

Usually, search on a static site sucks. You either:

• Load a 5MB JSON blob of all your content (RIP mobile users).
• Pay Algolia or Elastic to index your site (overkill).
• Give up and just have an "Archives" page.

I took a different route.

At build time, a script takes care of the following:

• Walks through the posts/ folder to find every post.
• Parses each MDX file’s AST.
• Pulls out well-structured pieces such as headings, text, and frontmatter.
• Outputs a very compact search index ready for instant queries.

This index is baked into the build. When you press Cmd+K (or tap the search icon), we aren't hitting an API. We're querying a local, optimized trie structure that was generated during the build.

It's instant. It's offline-capable. It's free.

You want to build your own?

Keep an eye on my GitHub for the release.