"It usually works" is not a standard

A demo is easy. You run the happy path once, it works, everyone claps. Production is different. Production is the same automation running a thousand times, on real inputs, at 2 AM, three months later, after an app it depends on quietly changed how it works.

The gap between those two is where most small-business automations fail — not loudly, but silently. It stops firing, nobody notices for a week, and by the time someone does, a pile of leads or invoices has fallen on the floor.

Where automations actually break

It's rarely the clever part that fails. It's the plumbing:

• An integration changes its API or login, and the connection goes dead.
• A rate limit or outage makes a step fail, and there's no retry.
• A weird input shows up — an empty field, an emoji, a 40-page PDF — that the happy-path demo never saw.
• Something succeeds halfway and leaves the data in a confusing in-between state.

None of these show up in a five-minute demo. All of them show up eventually in production.

What dependable actually requires

The boring work is the valuable work. A system you can rely on has three things a demo doesn't:

• Error handling — when a step fails, it retries or raises a flag instead of silently giving up.
• Testing against real scenarios and edge cases, not just the one input that looks good on screen.
• Monitoring — something is watching, so a break gets caught before you lose a week of work to it.

Questions to ask whoever builds yours

Whether it's us or anyone else, it's fair to ask: What happens when this step fails? How will I know if it stops working? What did you test it against? If the answer is a shrug, you're buying a demo, not a system.

We come at this from years of regulated quality-operations work, where “it usually works” was never an acceptable answer. The same discipline is what makes automation something you can actually forget about — in the good way.