On small, maintained software

Every few months someone asks why willc doesn’t make one big product. A platform. Something with a pricing page that has three columns and a “most popular” badge. The honest answer is that I’ve built those for other people, and I watched most of them quietly rot.

Small software is different. It fits in your head. You can hold the whole thing at once, which means you can keep holding it, year after year, without it slipping through your fingers.

The maintenance budget

Every feature you ship is a promise. Not a one-off cost — a subscription you pay in attention, forever. I started tracking it literally: a column in a spreadsheet for every feature, with a rough guess at how many hours a year it would cost to keep working.

The best code is the code you never have to think about again.

— Something I wrote on a sticky note in 2021

Here’s roughly how that budget breaks down for Tidewater today:

Area	Hours / year	Notes
OS updates	40	June is always busy
Sync	25	Down from 120 in 2025
Support	30	Mostly lovely emails
New features	60	The fun part

What this looks like in code

Mostly it means saying no to abstractions until they’ve earned their keep. When a config file appears, I want to know why before I know how.

// kiln.toml — the entire config for this site
title  = "willc"
output = "dist"

[feeds]
notes = "blog/feed.xml"

A few rules I try to stick to:

• If it needs a migration guide, it needs a very good reason.
• Dependencies are borrowed time. Pay them back early.
• Ship the boring version first; you can always make it clever later.

---

So, why four small things?

Because each one can be finished. Because when one has a bad month the others carry it. And because I’d rather be the person who still answers support emails for a ten-year-old app than the one who sunset it.¹

1. Pick a problem you have every week.
2. Solve the smallest true version of it.
3. Keep solving it, for as long as people need it.