We almost let our own automation cold-email its own founder

We were in the middle of repairing a broken cold-email queue on our own outreach pipeline. Part of the fix meant a backlog of contacts, stranded by the earlier bug, needed to rejoin the working pipeline. The plan, as written, was simple: merge the stranded backlog forward.

A merge like that is easy to trust. The rows had been collected before, the fields lined up, and the fix elsewhere was already done. Nothing about the plan looked risky on paper: it was a data operation, not new code, and data operations tend to get less scrutiny than the code around them.

The tempting move was to run it and move on. We did not do that. Before merging anything, we opened the actual rows and read them, the same way we would read the diff on a code change before shipping it.

The list was not what a clean prospect backlog should look like. It contained a federal .gov address belonging to a FOIA desk, two charity addresses, an immigration legal-aid nonprofit, a support inbox for a hosting platform, and a placeholder address left behind by a website-builder tool.

None of these rows were ever real prospects. They were the accumulated residue of however the original list had been built over time: a scrape, a form submission, a support ticket, an address typed into the wrong field once and never corrected. A list assembled this way does not announce which rows are bad. It just sits there looking like the rest of the data, until someone reads it closely enough to notice.

A merge treats every row the same. It has no concept of “this one is a government agency” or “this one is us.” Only a human looking at the actual data notices that some of those rows do not belong in an outreach queue at all, which is exactly why the step of looking cannot be automated away along with everything else.

Instead of merging the backlog as it was, we built a junk filter first: rules to catch government and military domains, our own company's own domains, known platform-support domains, and common nonprofit signals. Only after the filter existed did we run the actual migration.

Seven of 163 rows were junk by the filter's own rules. Thirty-three were contacts already known elsewhere in the pipeline. The remaining 123 were genuinely clean and migrated forward. The filter did not just catch the founder's own address. It caught six other rows an automation should never have been allowed to touch on its own.

Reading 163 rows by hand does not scale, and it was never meant to be the permanent answer. The filter is the durable version of the same instinct: instead of a human reading every row every time, a fixed set of rules reads them automatically and refuses to pass through anything that matches a known-bad pattern, before a single message goes out.

The same habit shows up in a plainer form as a dry run: a mode where an automation reports exactly what it would do, to whom, and how many times, without actually doing it. A dry run over this backlog would have printed the founder's own address as a send target in plain text, which is a much cheaper way to catch the problem than finding out after the fact. Any automation that touches real addresses, real accounts, or real money is worth running once in a mode that only reports, before it is ever allowed to act.

Most of the engineering attention that goes into an automation goes into making it run reliably: retries, error handling, logging, alerts when something fails. All of that matters. None of it would have caught this. The problem here was not that the automation broke. It was that it was about to work exactly as designed, on data nobody had actually looked at.

An automation inherits every defect already present in its inputs. “The list”, whatever list it is, almost always contains something you would be embarrassed to act on automatically, because it was assembled over time by processes that were never built to guarantee it was clean. A gate that checks who an automation is about to touch, before it touches them, is not optional polish. It is as load-bearing as the retry logic everyone remembers to build.

We keep this filter in place permanently now, on every list that feeds this pipeline, not just the one that happened to catch a founder's own inbox. The cost is a few seconds of automated checking before anything sends. The alternative, on a bad day, is an automation doing exactly what it was told to do, to exactly the wrong address.

This is the same standard we hold any automation to, ours or one we build for someone else: before it runs unattended at volume, someone has actually looked at what it would touch, and a permanent check stands in that person's place going forward. A list is never as clean as it looks from the outside, and the automation running against it will not notice the difference on its own.