I Built Fourteen Automations and Deleted Nine of Them

Over two years I built fourteen small automations — scripts, Zapier flows, a couple of shortcuts. Nine are gone. I deleted them at various points for various stated reasons, and when I put the list side by side, the difference between the survivors and the casualties was not the time saved, the complexity, or how often they ran.

It was whether the automation failed loudly.

The nine that died all failed silently. A Zapier flow that stopped firing because a permission expired, a script that started producing empty output when an API changed its date format, a shortcut that quietly did nothing on a system update. In every case the failure was discovered late, and in three cases the discovery was that something downstream had been wrong for weeks. After that happens twice you stop trusting the automation, and an automation you do not trust is worse than no automation, because you now do the task manually and also maintain the thing.

The five survivors all announce their failures. Two of them because they run in a terminal where I see the error. Two because they post their output somewhere I look daily, so an absence is visible. And one because I explicitly built a check into it — if it does not run by a certain time, it emails me. That last one is the only automation I ever added error handling to on purpose, and it is four years old and has never been touched otherwise.

The lesson I have taken is that the maintenance cost of an automation is not the code, it is the trust, and trust decays every time something goes wrong without telling you. So the first question before building anything now is: how will I know when this breaks? If the answer is “I’ll notice,” the honest translation is that I will notice in three weeks, and I should either add a signal or not build it.

The second thing the nine had in common, slightly less consistently: they automated a task that I did not fully understand. The date-format script is the clearest case — I automated a data cleanup before I had done it manually enough times to know the edge cases, so when it silently mangled a subset of rows I had no intuition that anything was wrong. The five survivors are all things I had done by hand many times first, which meant I could smell a wrong output.

There is a version of this advice that says do it manually a hundred times before automating, and I think that is too strong. But doing it manually until you can predict the output is a genuinely useful threshold, and it is usually about five times rather than a hundred.

The three automations I would rebuild if I lost everything: a script that renames and files the weekly export, which runs in a terminal where I watch it; a rule that turns any message containing an attachment from a client into a filed document with a consistent name; and the one that emails me if the backup did not run. Total time saved is maybe twenty minutes a week, which is not the impressive number the genre usually promises.

What they actually buy me is not the twenty minutes. It is that three specific things are now never forgotten, and forgetting was the expensive failure, not the doing. I think that is the general shape of a good small automation, and it is why time saved is a bad way to choose which ones to build.