The First Five Years Are the Hardest

4 January 2026 · ~6 minutes · blog

• writing
• this site
• longevity

This blog is seven years old this month, which makes it older than three of the four jobs I have held while writing it. I checked the archive before writing this: 2026 opens with 41 posts, of which 31 were written in the first two years. The decay curve of my output matches the decay curve of nearly every infrastructure blog I have loved, which is why I think I can name the causes.

Year one is free

Every long-running system, blogs included, spends its first year cashing in accumulated expertise. You have years of incident notes, strong opinions formed in email threads, and a backlog of “someone should write this down.” The first thirty posts are a withdrawal from that account, and it feels like income.

Year two is when the account runs dry and you discover whether you have a system for generating new material or only a memory. That is the year most blogs die, and not from laziness — from having mistaken a stock for a flow.

Where the flow comes from, for me

• Operations itself. Every on-call shift, every migration, every “why is this box at 100% disk” produces either a post or a runbook. I have stopped pretending I know in advance which.
• Answering the same question twice. The second time, I write the URL instead. Half my posts started as an email I had already written once.
• Revisiting old posts. The cron post exists because a 2020 post of mine on the same topic had a wrong section. Correcting your own archive is both content and hygiene.
• The maintenance log. Three weeks of ordinary upkeep became a post because I had started keeping the log. Material is a systems problem, not a talent problem.

What I got wrong for years

For the first three years I tried to write launch-shaped posts: new tool adopted, benchmark, conclusions. Those get links. They also age in dog years, and they train you to need news, which a long-running infrastructure practice does not produce on schedule. The posts people still email me about are the boring ones — cron, backups, review checklists — because they describe weather, not headlines.

The other mistake was treating the site as a publication instead of a place. The now page, the project pages that admit retirement, the visible corrections: those do more for trust than any post, because they show the site is inhabited. A blog with a working RSS feed and a current “now” page is more alive than most things called platforms.

Practical notes for year three and beyond

1. Keep the publishing stack dumber than your enthusiasm. This site is hand-written HTML on purpose: the friction ceiling is low, and the maintenance cost rounds to zero. Every generator migration I considered would have consumed a year of momentum.
2. Schedule the boringness: one evening a month, in the calendar, treating the blog like the cron job it is.
3. Let posts be wrong in public, and correct them visibly. An archive with a correction history is worth more than an archive that pretends to have been right.
4. Never break old URLs. The single longest-lived piece of infrastructure on this site is a 2019 redirect rule, and it has outlasted every framework I have evaluated since.

The actual point

Longevity is the only competitive advantage left on the independent web. Search engines discount you, aggregators ignore you, and none of it matters, because the readers who matter find you the way you found the sites you trust: while searching for a specific error message, at night, and staying. Everything on this site is optimized for that reader. Seven years in, they are the entire business model, and the first five years were the price of admission.

If you are reading this in year one of your own blog: the falloff is not failure, it is the handover point between memory and system. Build the system — a log, a queue of prompts, a fixed hour — and year three is easier than year one.

Newest post →