What I would automate first if I started over
# What I would automate first if I started over
Suppose everything I have built vanished overnight. Scripts, pipelines, schedules, the whole operation, wiped. A few years ago my answer to what comes first would have been something impressive, an ambitious pipeline chaining five systems together, the kind of thing that demos well. I have built enough of this stuff since then to know the impressive answer is nearly always the wrong first move. So here is what I would actually build, in order, and the principle behind the order, because the principle is the whole thing.
The principle nobody says out loud
Automate the thing you do every day and quietly hate. That single rule reshaped how I approach all of this, and it sounds almost too simple to matter. The target is never the most technically interesting problem or the workflow that would look good on camera. The target is the dull, repetitive task you perform on a normal Tuesday and never mention to anyone because it is too boring to bring up.
I burned a long stretch of my early setup time on the opposite. I built automations for edge cases, elaborate chains that triggered under conditions I had hit maybe twice. They were fun to build and they taught me very little, and they broke constantly, because complex things break constantly. Meanwhile the task I performed by hand every single day, for months, sat there untouched while I polished the flashy stuff. The hours were hiding in the boring daily grind the entire time.
The practical exercise: review your last five working days. Skip the ambitious projects and look at the five minutes here and ten minutes there that nobody would film a tutorial about. The routine that starts your day before real work can begin. The routine that closes it out. The prep you repeat every time a new piece of work arrives. Automatable time hides in plain sight, inside chores so routine you stopped calling them chores.
First: one script for the daily annoyance
Concretely, the first build is a small, reliable script that handles the one task I do literally every day and resent. For most people this is something almost embarrassingly basic. Moving a file from one place to another. Copying a number from a spreadsheet into somewhere else. Sending the same message in the same format again and again. Renaming a batch of things before work can start.
A two minute task feels like nothing until you multiply it: two minutes every day is about twelve hours a year, and the interruption cost is worse than the time, because each occurrence yanks your attention out of real work. Twenty lines of code, sometimes fewer, makes it disappear.
The reason this comes first has little to do with the time saved. A tiny automation teaches you the shape of the craft without endangering anything important. You build it, run it, verify the result, and feel what it means to hand a job to a machine. That feeling is worth more than the minutes.
Second: backups, tested once for real
Immediately after the first small win, backups. Boring even by the standards of boring things, and still the item I would rush to fastest, because nothing else I have learned compares to how quickly weeks of work can evaporate without them.
The scenario is always the same. You spend weeks getting a set of scripts and workflows exactly right. Then a drive fails, or an upgrade breaks something, or you overwrite a folder, or you run one bad command. With automated backups that is a bad afternoon. Without them it can be weeks of lost work.
The build is simple: a script on a schedule that compresses what matters and ships it somewhere that is not your machine. A cloud bucket or a second drive both qualify. Elegance is irrelevant. Running daily without your involvement is the entire requirement.
One step in this stage is non negotiable for me: restore something from the backup, once, for real, before moving on. A backup you have never tested is a comfort blanket. Verification is part of the automation, and I would build nothing else until it passed.
Third: a scheduler
The third build changes the character of everything before it. The daily annoyance script still runs when you run it. The backup runs on a timer you set by hand. A scheduler is the moment your setup starts having opinions about when things happen, waking up at a set time and doing the work whether you are at your desk, away, or asleep.
For me this was the shift from feeling like a person who runs tools to feeling like a person who owns a system. Jobs could fire at 3am. The daily file could be waiting when I woke up instead of being my first chore. A report could be ready before coffee.
The mechanics are trivial, under an hour on most operating systems. The significance has nothing to do with complexity. Your system starts working for you instead of waiting for you, and once you have felt that, you cannot unfeel it.
Fourth: one narrow assistant for the glue
The fourth addition brings in a little intelligence, and the operative word is narrow. Glue work is my name for the connective tasks too fuzzy for a plain script and too repetitive to keep doing by hand: drafting a routine message from a template, pulling a plain language summary out of a log file, generating a filename that follows a naming convention from a rough description.
The build is one small tool for exactly one of those tasks. Whichever glue job costs the most time, that one, alone. Never a general purpose assistant, never something steering the whole workflow. One job, a well defined input, and output you can check in five seconds.
It sits fourth for a reason. An assistant only earns its keep once a real daily workflow exists for it to plug into. Built before the fundamentals, it becomes something clever floating on nothing. The daily task is the ground. Backups protect the ground. The scheduler makes the ground operate without you. The assistant helps with work happening on the ground.
What stays off the list
I want to be equally direct about what I would refuse to build first, since this is where most people go wrong and where I went wrong myself. Nothing complex. No multi step pipeline with six dependencies and three failure modes. No end to end workflow copied from an impressive demo. No dream system.
I say this having built versions of all of it and watched them break in ways that are demoralising to debug when you are still learning fundamentals. A simple automation failing is a clear lesson: you see what broke, you fix it in an hour. A complex automation failing is a mystery, with the lesson buried under layers of interconnected problems, and early on you lack the map to untangle the mystery quickly. Two weeks disappear into debugging something a simpler version would have exposed in a day.
Start with what fits in your head all at once. Start with something that fails loudly. The complex build feels like the real work and the small build feels like practice, and that instinct is exactly backwards. Most of the durable automation running in my operation today looks far more like the simple version than like the ambitious designs I sketched at the start.
Small and proven, then the next piece
The last habit I would change connects to everything above: resisting the pull of the big plan. A dream system is extremely easy to imagine and extremely hard to build, and the imagining happily consumes the hours the building needed.
Everyone I have watched build something genuinely reliable did it one way. One small thing, proven working. Another small thing, proven. Then the next. A system slowly emerges that has never been broken, because every piece was verified before another piece leaned on it. The alternative, designing everything up front and connecting it all at once, ends in debugging a machine where every part is untested and every part depends on the others, which is among the worst experiences this work offers. The incremental path feels slower and looks less impressive, and it finishes sooner. When it is done, you trust it, because you watched every piece earn its place.
So, starting over tomorrow: one small script for the daily task I hate, verified and left alone. Backups, tested by an actual restore. A scheduler, so work happens without me. One narrow assistant for one dull glue job. Nothing more ambitious until all four run cleanly. Everything I operate now began exactly that small, and no single step ever felt like the important moment, though each one was. The thing that built the operation was never ambition. It was the patience to prove each piece before reaching for the next.
I write up the unglamorous side of running systems like this on [the home page](/).
Get new guides and videos first — join the Telegram channel.