Why I Keep Blog Posts in Plain Markdown

Writing on a personal site should feel like writing—not like administering a product.

That is why I keep my posts in plain Markdown. A post is a small text file with a little metadata at the top. It sits beside the source code for the site, goes through the same reviewable history, and is rendered when the site is built. No database, no dashboard, no content workflow to maintain.

For a personal blog, that is not a limitation. It is exactly the point.

The tool should stay out of the way

I spend most of my time thinking about systems: boundaries, integrations, workflows, and the choices that make software easier to change years later. When I have an idea worth keeping, I want the shortest possible path from a blank page to a published note.

Markdown gives me that path. I can draft in any editor, focus on the argument, and use a small, familiar vocabulary for headings, emphasis, code, and links. The format is readable before it is rendered and still useful if the site disappears tomorrow.

Content belongs with the code that presents it

This site is deliberately small. Its posts live in source control alongside the templates and the code that renders them. That means the history of a post is clear: what changed, when it changed, and why. It also means I can make an editorial correction in the same focused change as the supporting implementation, when the two genuinely belong together.

The publishing model is refreshingly boring:

write a markdown file -> commit it -> deploy the site

“Boring” is a compliment here. Every additional moving part creates another thing to configure, secure, update, and eventually replace. A personal site earns the right to become more complex only when the writing actually needs it.

Durable formats make good long-term choices

After decades of building and maintaining software, I value formats that remain understandable when fashions change. Markdown is plain text. It does not depend on a vendor’s editor, a proprietary export, or a particular version of a CMS. A future version of this site can render these files differently without requiring me to migrate the writing first.

That independence matters to me. The blog is a record of ideas, decisions, and lessons learned. Its content should outlast its current design.

Enough structure, not too much ceremony

Markdown is structured enough to be useful. Frontmatter describes the title, date, category, summary, and tags. The body carries the actual writing. The site can sort posts, build an index, and present a consistent reading experience without asking me to fill out a form for every paragraph.

It is the same principle I prefer in software design: use the simplest mechanism that clearly solves the problem, then add complexity only when there is evidence it is needed.

Plain Markdown lets this blog stay focused on what it is for: sharing useful thoughts about building software, designing systems, and improving the way we work. Everything else can remain pleasantly invisible.