Building small tools that last

The tools I keep using tend to do a small thing clearly. A text file for a project log. A script that prepares images. A page that keeps references together. None tries to become the centre of every working day, and that restraint gives them room to last.

Choose a boundary you can explain

For a personal project, I try to describe the complete job in one sentence. That sentence is a practical boundary: it helps decide whether a feature belongs now, whether it needs a separate experiment or whether the existing tool already does enough.

A narrow scope also makes maintenance more honest. I can understand the data model, exercise the important failure paths and recognise when a dependency adds more complexity than the problem needs. The project remains something I can return to after a few quiet months.

Make leaving possible

Plain formats and straightforward exports matter even for small tools. A useful collection should remain useful outside the interface that created it. Thinking about export early often reveals unnecessary coupling between the content and the way it is displayed.

I still make experiments that exist for an afternoon. They have a different purpose. When an experiment starts becoming a tool, I want its next feature to make it easier to trust and maintain. More capability can wait until there is a concrete job for it.