Hand repetitive work to machines with automation: an efficiency system for one person
Automation isn't about writing complex scripts; it's about finding the things you do manually every week. Clarifies the selection criteria, tool choices, and a minimal setup you can start with right away.
Many people get automation backwards: learn the tool first, then look for a scenario. The result is a bunch of flashy but useless flows.
The right order: record repetitive work first, then decide whether to automate.
Step 1: log for two weeks
Take a spreadsheet and add a row every time you do a “repetitive action”:
| Action | Frequency | Time per run | Weekly total |
|---|---|---|---|
| Consolidate weekly report data | every Friday | 40 min | 40 min |
| Make cover images for posts | per post | 15 min | 30 min |
| Sync publishing across platforms | per post | 20 min | 40 min |
After two weeks you’ll have an honest list. Most people find they spend 5–8 hours a week on completely mechanical things.
Step 2: filter with three conditions
Not every repetitive task is worth automating. Only act when all three hold:
- Happens at least once a week
- Takes more than 10 minutes per run
- The rules can be written down clearly (no on-the-spot judgment needed)
The third is the easiest to overlook. If you yourself can’t say clearly “what does it take to do this right,” then you can’t automate it — standardize first, then automate.
Step 3: pick a tool, tiered by complexity
| Complexity | Tool | Typical scenario |
|---|---|---|
| Low | system shortcuts / text replacement | fixed phrasing, paths |
| Medium | Raycast / Alfred workflows | combined actions, template generation |
| Medium-high | n8n / Make | cross-platform data sync |
| High | custom script + cron | tailored processing |
Start from the lowest tier. I’ve seen someone build a 20-node n8n workflow that a single text replacement could have solved.
A setup you can start with right away
This weekly flow suits almost everyone:
#!/usr/bin/env bash
# weekly.sh —— run once Friday afternoon
set -e
# 1. Summarize this week's changes
git -C ~/vault log --since="1 week ago" --oneline > /tmp/week.txt
# 2. Draft the weekly report
claude -p "Read /tmp/week.txt and draft a weekly report in three sections — Done / In progress / Blocked — under 200 words"
# 3. Backup
rsync -a ~/vault/ /backup/vault/Three things: summarize, generate, back up. Used to take 25 minutes; now 30 seconds.
Three easy traps
1. Automating things that shouldn’t be automated
When you automate something that needs judgment, the errors it produces cost more than the time it saves. Anything involving external publishing, money, or irreversible operations — always keep a human confirmation step.
2. No failure alert
Silently failing automation is more dangerous than no automation — you think it’s running, but it actually died three months ago.
# Notify on failure, don't fail silently
claude -p "..." || notify "Weekly report generation failed"3. Never reviewing after automating
Flows rot: APIs change, directory structures change, requirements change. Spend half an hour each quarter checking that all your automations still work.
Closing
The goal of automation isn’t “making the system complex,” but getting you to do a few fewer things each week that don’t need your judgment.
The test: after installing this, did you actually use that time for something more important? If not, you just swapped one form of busyness for another.
Follow me
