How this blog works

Tamarind is being built in the open, and this is where the reasoning gets written down. Before any of that, a short note on the machinery underneath, because the choice says something about how we prefer to build things.

There is no content management system here. A post is one file:

content/blog/how-this-blog-works.mdx

The filename becomes the URL. This file is at /blog/how-this-blog-works. Renaming the file changes the URL, which is worth remembering once a post has been shared.

Writing a post

Every post starts with five lines of metadata:

---
title: How this blog works
description: A short summary, used on the index page and in search results.
date: 2026-08-26
author: Tamarind
published: true
---

Below that is ordinary Markdown. Headings, lists, links, quotes, tables and code blocks all behave the way they do in a pull request description, which is where these files get reviewed anyway.

Two extra components exist for the cases Markdown does not cover well. The first places an image with a caption:

The second sets a short aside apart from the surrounding text:

That is the entire component library, and it is meant to stay small. A blog that needs a component system has stopped being a blog.

Drafts

A post with published: false stays in the repository and stays off the site. It is not listed on the index, it is not in the sitemap, it is not in the feed, and its URL returns a 404. So an unfinished post can be committed, pushed and reviewed like anything else, without a separate staging environment and without a preview link that leaks.

Publishing

Flip published to true, open a pull request, merge it. Vercel builds the site and the post is live. The whole history of a post — every revision, every correction — is in the Git log next to the code it describes.

It is a deliberately boring setup. Boring means there is nothing to maintain, nothing to migrate, and nothing standing between having a thought and writing it down.