Why I Built This Blog the Way I Did

By Dylan4 min read

There's something deeply satisfying about a system where your words live as plain text files in a folder, tracked by Git like any other code. No database to corrupt, no admin panel to hack, no vendor lock-in to worry about. Just Markdown files that will be readable in fifty years, long after whatever blogging platform is fashionable today has shut down its servers.

The Platforms I've Left Behind

I've used WordPress, Medium, Ghost, Notion, and probably a dozen other platforms over the years. Each time, I eventually hit the same wall: the platform's assumptions about what a blog should be didn't match what I actually wanted to write. WordPress wanted me to think in terms of posts and pages and categories. Medium wanted me to optimize for engagement metrics I didn't care about. Ghost was beautiful but felt like overkill for someone who just wanted to think in public.

The turning point came when I realized I was spending more time fighting with CMSs than actually writing. Every platform had its own way of doing things, its own plugins to manage, its own security updates to worry about. I started asking a question that might seem backwards: what's the simplest possible system that wouldn't get in my way?

The Answer Was Embarrassingly Simple

A folder full of Markdown files. A static site generator to turn them into HTML. Version control to track changes. That's it.

The choice of Next.js wasn't obvious at first. For a site this simple, I could have used Hugo or Jekyll or even hand-written HTML. But I spend my days writing React, and there's something to be said for using tools you already know. More importantly, Next.js gives me an escape hatch—if I ever want to add something dynamic, I can do it without rebuilding everything from scratch. The static generation means the site is fast and cheap to host, but the React foundation means I'm not painting myself into a corner.

How It Actually Works

The implementation is almost disappointingly simple. Each blog post is a Markdown file with some metadata at the top—title, date, tags. When Next.js builds the site, a small library called gray-matter parses this frontmatter, and remark converts the Markdown body into HTML:

const { data, content } = matter(fileContents);
const processedContent = await remark().use(html).process(content);

That's essentially the entire "backend" of the blog. There's no database, no CMS, no admin panel. The file system is the database. Git is the version control. My text editor is the writing interface.

Next.js's file-based routing means a file at content/blog/my-post.md automatically becomes a page at /blog/my-post. When I want to write, I open my text editor. When I'm done, I commit and push. The site rebuilds automatically on Vercel. The whole process takes maybe thirty seconds from finishing a draft to seeing it live.

What This Approach Gives Up

I should be honest about the tradeoffs. This setup isn't for everyone. If you're running a publication with multiple authors and an editorial workflow, you need something more sophisticated. If you're not comfortable with Git, the deployment process will feel alien. There's no WYSIWYG editor, no media library, no scheduled posts out of the box.

But for a solo writer who already lives in a terminal, these "missing features" feel more like liberation. Without a rich text editor, I can't fiddle endlessly with formatting. Without analytics dashboards, I'm not tempted to optimize for clicks. Without comments, I'm not performing for an audience. The Markdown file is just me and my thoughts.

Tools Shape Thinking

There's a deeper point here about tools and creativity that I keep coming back to. Every tool embeds assumptions about how work should be done. A word processor assumes you want fonts and margins and page breaks. A blogging platform assumes you want social sharing buttons and SEO optimization. Sometimes those assumptions are helpful. Often they're distracting.

The value of a minimal system isn't that it's technically superior—it's that it has fewer opinions about what you should be doing. The blank Markdown file doesn't suggest anything. It just waits.

I've been running this setup for a while now, and I'm struck by how little I think about it. The site just works. Posts go up when I write them. Everything loads fast because there's almost nothing to load. The system disappears into the background, which is exactly what a tool should do.

If you're a developer thinking about starting a blog, I'd encourage you to consider something like this. Not because it's the best solution—there is no best solution—but because building your own system forces you to think about what you actually want. And sometimes, stripping away the features reveals that most of them were never about writing at all.