Five questions before you automate anything

1. Can I describe the correct outcome in one sentence?

Not the steps — the outcome. “Every photo from the camera ends up on the server, once, with its date intact.” If your sentence contains “and” more than twice, or contains “usually”, you have more than one task or an unmade decision. Split it or go make the decision.

2. Has the process been stable for three months?

If the steps changed last month, they will change again next month, and you will spend more time editing your automation than you ever spent doing the task. Stability is not a nice-to-have; it is the precondition. Wait.

3. What happens if it runs twice by mistake?

This is the question that separates people who have run automation in production from people who have not. Things run twice. A retry fires, a schedule overlaps, someone clicks the button again.

If running twice is harmless, you are in good shape — that property is called idempotence and it is worth designing for deliberately. If running twice sends two invoices, deletes two generations of files, or charges a card twice, you must build a guard before you build the automation, not after the incident.

4. How will I know it worked — without checking?

Not “how do I check”. You will not check. Nobody checks a thing that has worked for ninety days. The question is what actively reaches you when it stops working.

“It sends me an email when it succeeds” is a trap: within two weeks you will filter those emails, and then the silence of failure will look exactly like the silence of a filtered success. Design the alert around the absence of the expected result, not the presence of a success message.

5. What is the manual fallback, and who knows it?

When it breaks — at the worst time, because that is when load causes breakage — what does a human do? If the answer is “wait for Ben”, you have not automated a task; you have created a dependency on one person. Write the fallback down, in the same place as the automation, and make sure someone other than the builder has done it once.

Scoring it honestly. Five clear answers: build it. Four: build it, but fix the gap first. Three or fewer: the automation is not the work yet. The work is the questions you could not answer, and it is almost always a conversation or a decision rather than code.