Blog rethink

This blog had three problems, and I had been living with all of them for years.

The column was too narrow for code. The pages didn’t look like they belonged to the same site. And nothing on it said who I am today: a visitor who came from a talk or a GitHub repo found a site called “D34dBlog” and an author box that said “Spice Dealer”.

I could have opened the theme and started fixing things. Instead I wrote the problem down first, as a study: what is wrong, which decisions it needs, what others did, and where it should land. This page is that study, told as a story. The full record, with every option I weighed, sits behind it.

What was actually wrong

Complaints are cheap, so I measured. A scripted browser loaded eight pages at desktop width, at phone width and in dark mode, and read the computed styles. The audit found more than I expected:

• Every post was wider than a phone. The page measured 449 px on a 390 px screen, so every line of text was cut off, not just the code. Most links to the blog come from LinkedIn and chat, and those open on phones.
• The brand font never loaded. The setting sat where Tailwind ignores it, so every reader saw their system font, and the preload was wasted bandwidth.
• Dark mode didn’t switch on. The theme was registered under the wrong name.
• The title lost to its own headings. Post titles were 30 px regular; section headings were 30 px bold.
• The support box won the page. Above the fold, four things competed for the eye, and the box asking for a coffee had the heaviest border.

Underneath the visible problems was the build. Posts, styles and the two interactive apps took three separate routes into Hugo. The Svelte apps only stayed up to date if I remembered to rebuild and commit the compiled JavaScript by hand.

Not everything was bad, and that mattered too. Pages were light (about 140 KB), there were no trackers, and the paragraphs read well. Whatever came next had to keep those.

The question underneath: what is the site for?

Most of the reading complaints have different fixes depending on one answer. A technical journal puts the article first. A project hub puts the projects first. An author home with a journal puts the person and the work first, and the writing sits inside that.

I picked the author home. FlowDrop, Atelier, Sutram and Revision Graph used to appear only as post categories. Now they have a place on the home page, and the profiles a visitor actually wants (GitHub, drupal.org, LinkedIn, the talks record) are one click away.

Three widths, not a wider column

The obvious fix for “too narrow” is a wider column. It is also wrong: about 70 characters is the right width for paragraphs. The problem was that code, tables, diagrams and apps were stuck at that width too.

So a post now sits on one grid with three named widths: text for prose, wide for code, tables and side-by-side comparisons, and full for big figures. The sidebar is gone from posts. Support moved to the end, where it asks politely instead of shouting.

One toolchain

Hugo itself was never the problem. It is fast, and the posts are plain Markdown. The pain was in the joins around it. Once I decided that interactive pieces should live inside posts, rather than as apps on their own pages, that one choice settled most of the stack question.

I compared three directions: keep Hugo with a new theme, move to Eleventy, or move to Astro. Keeping Hugo meant keeping a second build for components, which was the thing I wanted to get rid of. Eleventy is simple and fast, but the Svelte apps would have needed their own toolchain again.

Astro won: posts, studies and components in one build, with schema-checked content. I knew the price going in: thirteen shortcodes to convert, a redirect for every old URL, both apps upgraded from Svelte 3 to 5, and a framework whose major versions move fast.

A blog you can type at

Today a reader, or an AI agent, can only click and scroll. I build Sutram, a package that turns what a web app can do into commands that people type into a console and agents call as tools. A blog that doesn’t use it would be a missed demo.

There were three levels to choose from: make the site machine-readable, add a Sutram console with WebMCP tools on top, or go further and add an AI assistant that answers questions. I stopped at the console: visible, themed, with commands like posts search and studies read. Every post and study also has a Markdown copy and an llms.txt entry, so agents don’t have to scrape HTML. The assistant can wait until the commands have proven themselves.

The call I’d argue with

The audit bugs were all small fixes on the old site, and the recommendation was to fix them right away. I said no, and decided to fix them only in the rebuild.

That meant the mobile overflow stayed live for the whole rebuild. It was the right call for focus and the wrong one for anyone who opened a link on their phone in those weeks. I’m writing it down because a study that only records the good decisions isn’t much of a record.

Studies as a content type

The last decision was how to publish studies like this one. Rewriting each one as a normal post would lose the structure, and linking to the live working page would publish the mess. So studies became their own content type: numbered, with a state, and rendered from the study file itself.

The first version of this page did exactly that, and it read like a dump: twenty questions, every option at full length, and the answer near the bottom. A record is for the people deciding. A reader needs the story. So every study now opens with an essay, like this one, and keeps the record one click away.

Where it landed

The site you’re reading is the result: an author home with a journal, on Astro, with a three-width reading grid, an identity of its own (which got a study of its own), components inside posts, and a console you can type at. Every old URL redirects to its new home. The legacy posts moved over with an “archived” banner instead of disappearing.

“Done” was written down before any code was: no horizontal scroll from 320 px up, light and dark both working, Lighthouse 95+ on performance, accessibility and SEO, home and post pages under 150 KB, and a link preview that shows up on LinkedIn.