The Boring Automation Manifesto: Simple, Observable, Easy to Repair

The automation that impresses people in a demo and the automation that's still running in two years are almost never the same build. The impressive one chains eleven steps, touches five tools, and does something clever with AI at every joint. The durable one moves one piece of data from A to B, writes down what it did, and complains loudly when it can't.

We build the second kind on purpose. After enough years of building — and, more instructively, repairing — automations for solo operators, the philosophy fits in a sentence: simple, observable, easy to repair. Every build has to pass all three tests. Here's what each one means, and why cleverness is the thing we're defending against.

Clever breaks silently. That's the whole problem.

The failure mode of a clever automation is not that it breaks. Everything breaks — APIs change, tokens expire, a vendor renames a field on a Tuesday. The failure mode is that it breaks silently, and the person depending on it has no idea.

The pattern we see over and over: an operator has an eleven-step flow that someone built for them, or that they built themselves at midnight feeling ambitious. Step six fails quietly in March. They find out in May, when a client mentions they never got their onboarding documents. Two months of a business process just — not happening. No error, no alert. The automation didn't fail loudly enough to be noticed, and it wasn't simple enough for its owner to check.

For a solo business this is worse than having no automation at all. When you did the task by hand, at least you knew whether it happened.

Test one: Simple

One automation, one job, explainable in one sentence. "When an invoice is 3 days overdue, send the first reminder." "Every Friday at 4, compile the week's numbers into an email." If describing a build requires the word "then" more than twice, it should probably be two builds.

Simple isn't a limitation; it's a load-bearing choice. Small single-job automations can fail independently, get tested independently, and get replaced independently. The eleven-step flow is a chain — one dead link and the whole thing stops, usually somewhere in the middle where nobody's looking. Three linked four-step builds survive what one twelve-step build won't.

Test two: Observable

You should be able to answer, in under a minute, "what did this thing do this week?" Concretely: every automation we ship writes a log a human can read, and the important ones send a digest — sent 4 invoice reminders, updated 23 CRM records, flagged 2 items for review.

The digest isn't decoration. It's how trust survives contact with reality. An automation you can't observe is one you'll either anxiously double-check forever — which erases the time it saved — or ignore completely until it burns you. Neither is a system. Both are a mood.

If you can't see what an automation did, you don't have an automation. You have a rumor about one.

Silence should mean "nothing needed doing," and you should be able to verify that. A weekly "checked 31 invoices, none overdue" line costs nothing and buys certainty.

Test three: Repairable

When — not if — a build breaks, the questions are: how long until it's running again, and who can do it? Repairable means minutes, and the answer to "who" includes people who didn't build it.

What that looks like in practice:

Failures announce themselves. A break sends a notification the same day, not whenever someone notices downstream.
Errors speak plain language. "Couldn't reach QuickBooks — reconnect the account" beats a stack trace.
The pieces are standard. Ordinary tools, plain integrations, no bespoke glue that only its author understands.
There's a one-page note per build: what it does, what it touches, what to check first when it stops.

Repairability is also an independence test. If your automation only runs while a particular freelancer answers Slack messages, you don't own a system — you rent one. We document our builds so that a client could, in principle, fire us and keep everything running. That's the standard.

The checklist

Run your existing stack — the Zaps, the scripts, the AI workflows — through the same three gates. For each automation you have:

Can you say what it does in one sentence, without "then, then, then"?
Can you see, right now, what it did in the last seven days?
If it broke this morning, would you know by tonight? Could you — or anyone — fix it by tomorrow?

Anything failing two or more gates is a liability wearing a productivity costume. Either simplify it, add logging and alerts, or decide the task didn't need automating in the first place — a real option more often than you'd think.

The goal was never impressive machinery. The goal is a business that runs like a team of ten while staying a team of one — and that only works if the machinery is the kind you can safely ignore. Boring is what safe-to-ignore looks like from the inside.