Built in an afternoon, broken by Christmas: what makes an automation last

The engineering that decides whether an automation is still working next year has almost nothing to do with AI. Five old habits do most of the work: say every rule once, be able to see what actually happened, decide in advance what happens when a step fails, make it safe to run twice, and be able to go back. None of them are difficult to ask for.

Building an automation has become genuinely easy. An ops manager with an idea and an afternoon can wire an inbox to a spreadsheet to a CRM and have something valuable running before the end of the day, and it will work. What hasn't become easy is keeping it alive. The gap between those two things is engineering, and most of it's a handful of principles that software engineers have been arguing about since long before anyone was automating anything with AI.

You don't need to be able to build any of this. You do need to be able to tell whether the person who did has thought about it, which is a different skill. Below are five of those principles, what each one means in a business, and the single question you should ask about each one.

Why do fifty-year-old engineering ideas suddenly matter to non-technical people?

Because the building moved, and the habits did not move with it.

Ten years ago, anything that passed data between two systems was built by tech, where these disciplines were assumed knowledge. Today, it's often someone in operations, finance or sales who saw a problem and solved it. That's a great development, and I love to see it, but the tools handed over the building without handing over the discipline, and nothing in a workflow tool's onboarding mentions any of this.

The consequence shows up six to twelve months later, and it's always the same shape. Something that matters runs on a workflow one person built - that person has changed role or left and now it's quietly holding up the house. Nobody can safely change it, and nobody is completely sure it's still doing the right thing. At that point you don't have an automation problem, you have an archaeology problem, and those are expensive.

DRY: what happens when the same rule lives in nine places?

DRY stands for "don't repeat yourself", and it comes from Andrew Hunt and Dave Thomas's 1999 book The Pragmatic Programmer, which put it as: "every piece of knowledge must have a single, unambiguous, authoritative representation within a system."

Strip the phrasing away and it's something every business already understands badly. Consider where your prices live: The website. The quote template. The CRM's product catalogue. A pricing spreadsheet. The proposal document somebody copied last March. One person's head. Putting prices up is then not one job, it's six, and you discover the one you missed three weeks later when a customer quotes the old number to you.

Automations accumulate the same problem faster, because copying a step is easier than copying a document. The instruction that tells an AI step how to categorise an expense, pasted into nine workflows. The discount rate typed directly into four calculations. The approval threshold of £5,000 written into a condition in three places, because each one was built by a different person in a different month. The decision about which AI model a step calls, made separately in thirty different places, which is exactly how a sensible tool choice hardens into a lock-in problem and why one place should own that decision, whether that's a gateway or simply a single shared setting.

The nuance that stops this becoming a crusade: DRY is about knowledge, not about text looking similar. Two rules that happen to say the same thing today but exist for different reasons should stay separate, because one day one of them will change and the other should not. Merging them feels tidy and creates a trap, where editing the invoicing rule silently changes the payroll one. Duplication is a cost. The wrong shared rule is a bigger one.

The question to ask: "If that rule changed tomorrow, how many places would you have to edit?" Any answer above one is a list of places to forget.

Observability: could you prove what your automation did last Tuesday?

Monitoring answers the questions you knew to ask in advance. Is it running? Did it error? Observability is the broader property: as the OpenTelemetry project defines it, "understand a system from the outside by letting you ask questions about that system without knowing its inner workings", which is what you need for the problems nobody anticipated (OpenTelemetry).

The business version of that is bookkeeping. Nobody keeps receipts because they like receipts, they keep them because on the day someone asks a hard question about a transaction from March, the receipt is the only thing that ends the conversation rather than starting an argument. A log is a receipt for a decision your automation made on your behalf.

So every run should leave one: what came in, what went out, which model or rule made the call, what it cost, and what happened next. Recording that is perhaps an hour of the build. Reconstructing it afterwards isn't expensive, it's impossible, because the information never existed. It's the single cheapest thing on this page and the one most often skipped, because on the day you build it there is nothing to look at.

It matters more for AI than for anything else, for one uncomfortable reason. Conventional software fails loudly: something goes red and you know. An AI step fails plausibly. It returns a confident, well-formatted, wrong answer, the queue keeps clearing, and nothing anywhere goes red. Without a record of individual decisions you cannot tell the difference between an automation that's working and one that stopped being right in June. What to watch once you have the record is a longer subject, and I have written it up separately in how to keep AI automations reliable.

The question to ask: "If this got something wrong last Tuesday, could you show me which one, and why it decided that?" If the answer contains the word "probably", there is no observability, whatever the dashboard says.

Error handling: what does it do when the other system is down?

Error handling is a kitchen question. The fish delivery didn't arrive - what happens next was decided in the morning, by people who are calm, and not at seven in the evening by whoever happens to be nearest the door.

Every step in an automation can fail, and most of them will at some point, because the other end is a supplier's system you don't control. A failed step has three acceptable outcomes:

• Try again. Most failures are momentary. A couple of retries with a pause between them clears the majority of them and nobody ever needs to know.
• Tell someone. Park the item somewhere visible with its context attached. Handing work back to a human is a designed outcome, not an admission of defeat.
• Do something else. Sometimes things break in predictable ways, and we know how to work around them. If the step that sends a WhatsApp message fails, send an email instead.

There is a fourth outcome, and it's the one that causes real damage: carry on as though nothing happened. It's a tick box in most workflow tools, usually called something reassuring like "continue on error", and it gets ticked because it makes everything go green. The result is a letter that's neither delivered nor returned to sender. Nobody knows it's missing, because silence looks exactly like success.

The question to ask: "Show me what happens when that step fails. Who finds out, and how long does it take?"

Idempotency: is it safe to run the same thing twice?

An ugly word for a simple idea - something is idempotent if doing it twice leaves you where doing it once did. Pressing the lift button twice doesn't summon two lifts. Paying an invoice twice very much does produce two payments.

This matters because reruns are completely normal and not usually anyone's decision. A connection drops halfway through and the job restarts. Someone re-uploads a file because they weren't sure the first one worked. Someone clicks the button twice, because everyone clicks the button twice.

If the automation was built to create a record each time rather than to update the right one, none of these produce an error. They produce a duplicate. Duplicate purchase orders, two credit notes for the same invoice, a customer thanked twice for the same enquiry, a payment run that goes out again. Errors get found by monitoring; duplicates get found by customers.

The payments industry treats this as table stakes - Stripe's API supports idempotency specifically so that a request can be safely retried by attaching a unique key to each one so the second attempt is recognised as the same instruction rather than a new one (Stripe). In a workflow the same idea is mundane: every item needs a name the automation recognises, usually one it already has, such as the invoice number. Then the second run can say "I've already done this one" instead of doing it again.

For a client I automated roughly two hundred invoice line items a day between a workforce system and an accounting package (case study). At that volume, a workflow that can't recognise its own previous work doesn't cause an incident, it causes a reconciliation project.

The question to ask: "What happens if this runs twice on the same invoice?" The answer you don't want is "it shouldn't".

Version history: can you get back to the version that worked?

The shortest one, and the most commonly missing.

Engineers keep every version of everything, forever, with a note on each change saying why. The office equivalent is the difference between track changes and a folder containing proposal_final, proposal_final_v2 and proposal_FINAL_use_this_one. Everyone has lived the second version and knows exactly how it ends.

Most workflow tools have some form of version history. Few teams have ever checked how far back theirs goes, whether it survives the person whose account owns the workflow leaving, or whether the automations that run the business are backed up anywhere at all. Find out on a quiet Tuesday rather than on the Friday you need it.

The other half is knowing why. A one-line note per change, kept anywhere at all, is worth more than perfect version history with no explanation, because the question is never "what did we change" but "how long has this been broken".

The question to ask: "If a change breaks something on Friday afternoon, how do we get back to Thursday?"

Does this mean you need to hire an engineer?

Not for a two-step workflow that sends you a Slack message. Building small things yourself is one of the genuinely good developments of the last few years, and adding ceremony to a five-minute job helps nobody.

But somebody has to hold these habits for the things that matter, and it's a responsibility rather than a headcount. The risk with a self-built automation is almost never that it fails on day one, because you would notice and fix it. The risk is that it works, quietly becomes business critical, and then can't be changed by anyone.

That's worth naming properly, because it has a name. Ward Cunningham coined "technical debt" in 1992 to explain to his management why a working system still needed work: shipping quickly is like borrowing money, which is fine and frequently correct, so long as it's paid back. His line is the one to remember, because it's the part people miss: "every minute spent on not-quite-right code counts as interest on that debt" (c2.com).

The interest on an automation is paid by whoever has to change it next, and it's charged whether or not anyone has noticed. Taking that debt on deliberately for a two-week experiment is good commercial sense. Taking it on without noticing, for the workflow that issues your invoices, is how a saving turns into a liability.

What to ask whoever builds it

Five questions, in the order I would ask them. None require a technical answer, and the quality of the answer tells you more than the quality of the build.

A good builder will enjoy these questions, because they're the parts of the job nobody usually asks about. Anyone who's annoyed by them has told you something useful for free.

The bottom line

The difference between an automation that pays for itself for years and one that gets quietly switched off in November is rarely the cleverness of the AI in the middle. It's whether each rule exists in one place, whether you can see what actually happened, whether somebody decided in advance what failure looks like, whether it's safe to run twice, and whether you can go back.

That is perhaps a fifth of the effort on top of getting it working, it's entirely unglamorous, and it's the whole job. None of it requires you to understand the technology. It requires you to ask five questions and to notice when the answers are vague.

If you have something running that nobody has looked at in months, or you want the next one built with these in from the start, a thirty-minute discovery call will tell you which of the five you are actually missing. See process automation and n8n consulting for how I approach the work.