Guides / Automation / 6 min read / Updated 1 August 2026

What to automate first

The wrong first project is the interesting one. The right first project is the boring one somebody does every single day and quietly resents.

The scoring question

For every candidate, three numbers:

• How often does it happen? Daily beats monthly by a factor most people underestimate.
• How long does it take each time? Including the context switch, which is usually the larger cost for a five-minute task done six times a day.
• How identical is each run? If the steps change depending on judgment, you are not automating a process, you are trying to automate a person.

Multiply. The top of the list is where to start. This is unglamorous on purpose: the highest-value automation in most small businesses is a report somebody assembles by hand every morning.

Three things that almost always qualify

• Recurring reports. Somebody pulls numbers from three systems into a spreadsheet and pastes it into a chat. It happens on a schedule, the steps never vary, and the person doing it has nothing to contribute except their time.
• Moving data between tools. A form submission that has to become a CRM record, an order that has to reach the accounting system. High frequency, zero judgment, and the errors are expensive precisely because nobody notices a missing record.
• Watching for something and telling somebody. Whether a site is up, whether a job ran, whether a number crossed a line. Machines are better at vigilance than people and never get bored, which is the actual failure mode of a human checking a dashboard.

Three things that almost never do

• Anything where the answer depends on judgment. You can automate the gathering and the presenting. The decision at the end is why somebody is employed.
• Anything that happens quarterly. By the time it runs again you will have forgotten how it works, and it will have broken because something upstream changed.
• A process nobody has agreed on yet. If two people do it differently and both think they are right, automating it just picks a winner and hides the disagreement in code.

The failure nobody plans for

The dangerous outcome is not the automation that breaks loudly. It is the one that stops working quietly while everybody continues to assume it ran.

A sync that silently drops records for three weeks does more damage than never having built it, because the manual habit died the day it launched. So build these two things at the same time as the job itself:

• An alert when it fails, going to a person, not to a log nobody opens.
• An alert when it does not run at all. Different failure, different detection. A job that never starts produces no error.

Build, buy, or glue

• Buy when the problem is common and somebody sells the solution. Your invoicing is not a competitive advantage.
• Glue — a workflow tool connecting existing systems — when the pieces exist and only need joining. Fast, visible, and easy for a non-engineer to maintain, which matters more than elegance.
• Build when the logic is specific to how you work and no product models it. This is the most expensive option and the only one that produces something nobody else has.

Most first projects are glue, and glue is a perfectly respectable answer. The failure is building a bespoke system for a problem a fifteen-dollar-a-month tool already solves.

How to know it worked

Write down, before starting, what you expect to stop happening. "Nobody assembles the morning report by hand." "Nobody re-types orders into the accounting system."

Then check in a month. If the person still does it — because they do not trust it, or because it handles nine cases out of ten and the tenth is what makes it unreliable — the automation has added a system to maintain without removing the work. That is worth finding out early, and it is a common enough outcome to be worth expecting.