When NOT to Automate: A Contrarian Checklist for Founders

I build automation systems for a living, and the most valuable thing I do on some engagements is talk a founder out of one. Here is the checklist I use to decide when the machine stays off.

Automation is a liability you maintain forever

Every automation you ship is a small, always-on employee that never sleeps, never asks questions, and never notices when the world changed underneath it. That is the pitch. It is also the problem. A script is not a one-time purchase; it is a standing obligation. It has dependencies that drift, credentials that expire, an upstream API that renames a field, and an assumption baked in on day one that quietly stops being true on day ninety.

Manual work degrades loudly. A person falls behind, complains, escalates. Automation degrades silently. It keeps running, confidently, doing the wrong thing at full speed until someone downstream notices the damage. That asymmetry is the heart of good automation strategy: the decision is never "is this task annoying?" It is "am I willing to own this system for the next two years?" Most of the process automation pitfalls I get called in to fix trace back to a founder who answered the first question and never asked the second.

Don't automate a broken process — you'll just scale the mess

Automation is a multiplier, and multipliers are indifferent to sign. Point one at a process that works and you get more of a good thing. Point one at a process that is confused, contested, or undocumented and you get more of a bad thing, faster, with a codebase wrapped around the confusion so it is harder to fix.

Consider lead routing. A founder asked me to automate assigning inbound leads to sales reps because it was eating an hour a day. When I sat with the ops lead, the actual rule was "whoever's free, unless it's an enterprise logo, unless Dana already talked to them at a conference, unless it's a reactivation." There was no rule. There was a person applying judgment and calling it a rule. Automating that would have encoded one snapshot of a decision nobody had actually agreed on, and every misroute would have started a fight about what the system "should" have done. The correct first step was not code. It was making three people sit down and define routing on paper. Once the process is legible and stable, automating it is an afternoon. Before that, you are pouring concrete around a question mark.

Too rare to matter: when the payback never arrives

The math on automation is unforgiving and easy to skip. You are spending a fixed build cost plus an ongoing maintenance cost to save a variable amount of manual effort. If the task runs rarely, the saved effort never clears the bill.

Take an annual compliance report that takes a skilled analyst six hours. Six hours a year is real, but a robust automation for it might take three days to build and a few hours a year to keep alive as the source systems shift. You would spend a decade breaking even, and you would spend that decade maintaining a thing that runs once every twelve months — which is the worst possible cadence, because you have forgotten how it works every single time it fires. Rare tasks are exactly where a human with a checklist beats a script, because the human reloads context on the fly and the script does not. This is the quiet center of the manual vs automated question: frequency, not difficulty, usually decides it.

Manual work degrades loudly and automation degrades silently — it keeps running, confidently, doing the wrong thing at full speed until someone downstream notices.

Too much judgment: tasks where the edge cases are the whole job

Some work looks like data entry and is actually adjudication. Refund approvals are the classic trap. Ninety percent of refund requests are trivial and could be auto-approved on a few rules. The reason you employ a human is the other ten percent: the angry customer who is technically outside the window but represents a five-figure account, the pattern that smells like fraud, the edge case that is really a product bug you need to hear about. The exceptions are not noise around the task. They are the task. The routine ninety percent is just the price of having a competent person positioned to catch the ten percent that matters.

Automate that and you optimize away the only part with leverage. The right pattern here is assistive, not autonomous: let the system clear the obvious cases and surface the rest with context attached, so the human spends their judgment where judgment pays. When I built Ledger to extract and validate invoices, I made a deliberate choice not to let it silently post anything whose totals failed a math check — it flags them for a person. The automation's job is to make the human faster on the hard cases, not to pretend the hard cases don't exist.

When the process changes monthly: you're automating a moving target

Automation amortizes. It pays off over many runs of a stable process. So the stability of the process is a precondition, not a detail. If the steps change every few weeks — because the product is pre-fit, the market is teaching you something new each month, or the workflow itself is still an experiment — then anything you automate is obsolete before it has paid for its own construction.

Early-stage onboarding flows are the usual offender. A founder wants to automate the twelve-step process of setting up a new customer, but that process is genuinely different this month than last because they are still discovering what customers need. Hard-code it and you are not saving work, you are adding a rewrite to every future change. Manual-plus-a-good-runbook is the correct tool for a process that is still learning what it is. Automate the parts that have gone quiet and stable; leave the churning parts to people until they settle.

The maintenance tax nobody budgets for

Here is the line item that never makes it into the pitch: automation you did not touch is not automation that did not cost you. Integrations rot. A vendor deprecates an endpoint, an OAuth token expires, a CSV export gains a column and your parser chokes, a rate limit you never hit before starts throttling you at scale. Someone has to notice, diagnose, and fix each of these, and that someone is on your payroll.

A useful rule of thumb from what I have shipped: budget ongoing maintenance at fifteen to thirty percent of the original build cost, per year, for anything that touches a system you do not control. A weather-driven inventory sync that depends on three external APIs sits at the high end; a self-contained text transformation sits near zero. Over-automation is what happens when a team ships a dozen clever integrations, budgets zero for upkeep, and discovers a year later that half of them are silently broken and nobody can remember who owns them. The cost of automation is not the build. It is the build plus the tail, and the tail is longer than anyone wants to admit.

The one question that settles it: what breaks if this runs wrong at 3am?

When I cannot decide whether something should be automated, I stop weighing hours saved and ask one thing: what is the blast radius when this executes incorrectly, unattended, at three in the morning with nobody watching?

The answer sorts almost everything. If a text-to-SQL query in Lumen returns a wrong number on a dashboard, someone reads a bad chart and, at worst, asks a follow-up — low blast radius, safe to automate, and worth doing because it runs constantly. If an automated system wires money, deletes production data, emails your entire customer list, or approves something regulated, a 3am misfire is not an inconvenience. It is an incident with your name on it. Those tasks can still be automated, but they demand guardrails a simple script does not have: dry-run modes, hard limits, human confirmation on the irreversible step, and alerting that screams rather than whispers.

def should_automate(task):
    if not task.process_is_stable:      return "fix the process first"
    if task.runs_per_year < 12:         return "too rare — keep it manual"
    if task.judgment_is_the_point:      return "assist, don't replace"
    return "automate — with guardrails sized to the blast radius"

I make my living building these systems, so read this as testimony against interest: the best automation decision is often a smaller one than the founder walked in wanting. Automate the stable, frequent, low-judgment, low-blast-radius work, instrument it so it fails loudly, and leave the rest to the humans who are good at exactly the things machines are bad at. The goal was never to automate everything. It was to stop doing the work that a machine should have been doing all along, and to be honest about which work that actually is.