What I mean by automation that actually runs

Most small businesses I talk to have tried automation before. Zapier zaps that broke after two months. A chatbot nobody uses. A dashboard that stopped updating because the API key expired and nobody noticed.

The problem is not the tools. It is that most automation projects get built and then abandoned. Somebody ships a workflow, declares victory, and moves on. Six weeks later an API changes, a credential rotates, or the source data shifts, and the whole thing quietly stops working. The owner does not find out until a customer asks why they did not get a follow-up email.

When I say I build automation that actually runs, I mean I build for week six and week twenty-six, not just launch day. In practice that means a few specific things.

Logging that tells you what happened

Every step of every workflow writes to a log a non-engineer can read. When a customer calls and says, “I never got my onboarding email,” the answer is one search away. No engineer required, no console diving, no guessing.

Credentials that rotate cleanly

API keys, OAuth tokens, and service accounts get a written inventory and a rotation schedule. The system tracks what is set to expire and surfaces it before anything quietly breaks.

A human gate where it matters

Anything that publishes to the world, sends to a customer, or touches money has a human approval step. The approval is one click in an email. Fast for the operator, impossible for the system to bypass on its own.

Retries built in, not bolted on

Network calls fail. APIs go down. Rate limits hit. Every external call has retry logic with backoff, plus a clear “this finally failed” path that gets the right person’s attention. Failures are loud, expected, and recoverable.

A two-week soak before I call it done

I do not declare a system done at launch. I declare it done when it has run unattended for at least two weeks without needing a manual fix. If something breaks in those two weeks, that goes into the build, not the maintenance budget.

Documentation a real person can read six months later

Not API docs. Not architecture diagrams. A short, plain-language guide that says: here is what this does, here is who owns it, here is how to tell if it is broken, and here is the one phone number to call when something is wrong.

Why this matters for the math

The biggest failure mode I see in SMB automation is not a bad initial build. It is a system that worked for three months, then drifted, then quietly cost the business money for another six months before anyone noticed. The total cost of a system that mostly works is almost always higher than the cost of a system built to keep running.

Boring on paper. Worth a lot in practice.