Automate only what's stable enough to deserve it

One of the principles I come back to most is short: automate only what's stable enough to deserve it.

It sounds cautious. It's actually about speed. Automation multiplies whatever it touches. A good process, automated, gets faster and more consistent. A broken process, automated, fails faster, more consistently, and often more quietly than it did when a person was doing it and could notice something was off.

I work with Zapier, Pipedream, custom scripts, WordPress form add-ons, lead handoffs into CRMs and intake systems, and scheduled AI agents. The tools vary. The question that decides whether automation helps or hurts is the same every time: is the process ready?

Signs a process is ready

A process that deserves automation usually has these traits:

It's been done manually enough times that the steps are known, not guessed. Someone can walk you through it without saying "it depends" at every step.
Inputs and outputs are clear. You know what comes in, in what format, from where, and what should come out the other side.
Exceptions are defined. You know the common ways it goes wrong and what should happen when they do.
It's measurable. You can tell whether a run succeeded, and you'd notice if success rates dropped.
It isn't changing every week. The people who own it agree on how it works, and that agreement has held for a while.
Doing it by hand is costing something real: time, errors, delays, or one person becoming a bottleneck.

If all of those are true, automating it is usually a good decision.

Signs it isn't

The warning signs are just as recognizable:

The steps change depending on who's doing it.
Nobody can say what should happen when a field is missing or a record is a duplicate.
The process is still being argued about.
The data coming in is messy and gets cleaned by hand as part of the job, and nobody has written down how.
There's no way to tell if a run worked except someone eventually complaining.

A common version of this: a lead form feeds into a CRM through an automation, and it works most of the time. But certain submissions have always been fixed by hand because someone knew to look for them. Once the handoff is automated, nobody is looking anymore. Those records keep flowing in broken, and nobody notices until the downstream numbers stop making sense. The automation didn't create the problem. It removed the person who was quietly absorbing it.

That's the core issue. Manual processes often have hidden quality control built in: a human who notices. Automation removes that unless you replace it on purpose.

What to do first instead

When a process isn't ready, the answer usually isn't "don't automate ever." It's "stabilize first."

Write the process down as it's actually done, not as people think it's done.
Standardize the inputs. Fix the form, the field names, the formats, the required fields. Most automation failures start with inconsistent inputs.
List the exceptions and decide what should happen for each one, including "send it to a person."
Run it manually against the written version for a while. If the document keeps needing edits, it's not stable yet.
Decide what success looks like and how you'll measure it.

Often, this step alone fixes most of the pain. Sometimes you discover the process should be simplified or removed rather than automated at all.

Monitoring is part of the automation

An automation without monitoring is a process that fails silently. Every automation I build or inherit should answer these questions without anyone digging:

Did it run?
Did it succeed?
How many items did it process, and is that number normal?
What failed, and where did the failures go?

Practical ways to get there:

Alert on failures, but also on unusual silence. A lead handoff that processed zero records today may be more worrying than one that threw an error.
Send failures somewhere a human will see them, not into a log nobody reads.
Reconcile periodically. Compare counts between systems: form submissions versus CRM records, for example. If they drift apart, something is dropping data.
Keep a daily summary of what ran. I like a simple green/red status for scheduled work, which I described in Scheduled AI agents with a human in the loop.

If you can't monitor it, you're not finished building it.

Zapier, Pipedream or a script?

The tool choice matters less than the readiness question, but it still matters. Here's how I think about the tradeoffs:

Option	Good for	Watch out for
Zapier	Fast connections between common SaaS apps, non-developers owning the workflow	Per-task pricing at volume, limited logic, logic spread across many small zaps
Pipedream	Workflows that need real code between steps, API work, developers who want a hosted runtime	Still a third-party dependency, code living outside your main repository
Custom scripts on your own server	Full control, complex logic, sensitive data, high volume	You own uptime, monitoring, security and maintenance

A few rules of thumb:

Start with the simplest thing that will hold up. For a low-volume connection between two common apps, a hosted tool is often the right call.
Move to code when logic gets complicated or when you're chaining many small automations to fake one real workflow.
Keep sensitive data in mind. Every hosted automation tool is another place your data passes through. That's a tradeoff worth stating out loud, not just accepting by default.
Know who maintains it. An automation nobody on the team understands is a liability the day it breaks.

Choose the simplest architecture that will still scale. Sometimes that's a hosted tool. Sometimes it's forty lines of code on a server you already run.

AI makes this more important, not less

With AI, it's now easy to automate steps that used to require judgment: drafting replies, classifying incoming messages, summarizing records. That's useful. It also makes it easier than ever to automate a process that isn't ready, because the AI will produce something plausible even when the inputs are a mess.

The same rule applies, just more strictly. The process needs to be stable, the output needs to be measurable, and a human should approve anything that reaches a customer until the results have earned more trust. That's the approach I described in AI as an operating layer, not a chatbot.

Earned, not assumed

Automation is a reward a process earns by being understood, consistent and measurable. Get it there first. Then automate it, watch it, and keep a human close to the places where mistakes are expensive.

Automating too early doesn't save time. It moves the cost to later, when the problem is harder to see and more expensive to untangle.