Automating work somebody actually depends on
Picking the task worth automating, shipping it to people who will never read a log, and proving afterwards that it helped.
The demo is the easy part. The hard part is the fortnight after: the input arrives in a format nobody warned you about, the person it was built for stops using it, and you cannot say whether it saved anybody an hour.
What separates an automation that survives from a clever script is unglamorous — choosing a task with a countable before-and-after, handling the awkward input rather than the average one, and leaving something the owner can run without you. These posts cover the choosing and the proving.
Writing on this
- How to choose the first thing worth automating — Most first automations fail on selection, not engineering. Four tests that separate a task that will survive contact with real use from one that quietly gets abandoned. (2026-06-30, 4 min)
Courses that take it further
- Ship one automation — Take one real process end to end, put it in front of people, and measure what it did for six weeks. (26 lessons, 1255 min, 8 free)
- Automate a local business — Somebody else's business, somebody else's process, and a handover where you never get called again. (23 lessons, 1010 min, 4 free)
- Coffee break: the summariser you can prove is wrong — Twenty minutes to build it, twenty more to find out where it fails. The second half is the point. (2 lessons, 40 min, 2 free)