# Outbound: 12 emails, one per person, no follow-up, no tracking pixels

> Nothing audits a pipeline like having to sign your name to it

Window: Aug 30 to 31

The last mile of GTM engineering is not delivery. It is the point where you stop trusting your own output because someone else is about to read it. Errors in a pipeline built for yourself cost nothing. Errors sent under your real name have a name and an inbox attached.

## Key numbers

- Sends: 12 (One message per person. No follow-up, no tracking pixels.)
- Work email coverage: 12 of 12 (All resolved by the first provider in an 11-provider waterfall, so ten providers never fired. About 7 credits against an estimate of 13 to 25.)
- Total spend across the stage: ~508 credits (126 HTTP, about 375 agent research, about 7 email.)
- Reply latency: under 60 seconds (Capture is automatic. The join back onto the send row is manual, and the diagram says so.)
- Replies: 0 (Pre-registered expectation: 2 to 4 replies, 1 to 3 corrections, 0 to 1 meetings, 0 to 1 opt-outs. Zero is the actual outcome, so zero is the number on this page.)

## The gate lost to hand research

The automated gate passed 57 of 199 accounts. Five of the twelve accounts I actually sent had been filed EXCL_SALES_LED by that gate, and every one of the five had verified in-house billing work anyway. The gate measured self-serve checkout. The research measured in-house metering. Run unsupervised, the gate would have cost five of the twelve best accounts, including one of the two high-confidence builders.

## Twelve, when the brief allowed twenty-five

The volume cut came from the personalization bar rather than capacity. Only 12 accounts produced a finding specific enough to justify a send. One of the twelve findings is a bug report about my own scan, sent to the company anyway:

## Where the line is

The best-researched contact in the build was an engineer at a company that sells subscription billing infrastructure. Their working email was sitting in git commit author metadata on a personal domain, and their public work was exactly what I would have been asking about.

I did not send, for two reasons. The company runs on the processor I was writing about, so the claim in my email would have been wrong, and wrong in a way that gets forwarded. And the address was never published as a contact channel. It leaked as a side effect of committing code. The same pattern came up twice more in the build, and I never used it.

Reading someone's commit history to find out what they built is fine. Reading it to find out where to reach them is something else, and both start with the same git log. The line is not in the data. It is in what you do next with it.

## The seams, stated

Two things the tooling gets wrong about this build, published here because the paper trail should be better than the tool's. The reply join is manual: capture lands in Clay in under 60 seconds, but a Clay enrichment fires on changes to its own row and never on changes in the table it reads from, so the lookup back onto the send row is refreshed by hand. And Clay's lineage graph shows the send seed parented to a CSV rather than the source table. Every field traces back to the segment, and the lineage does not know that.

## What broke

Zero replies against a pre-registered expectation of 2 to 4. At twelve sends the sample is built to produce labelled corrections rather than pipeline, and a zero still gets published, in the same voice as everything else, because the alternative is a portfolio of only the runs that flattered me.

## Debrief

The primary metric of the whole build is corrections received: a reply naming the actual billing stack is a labelled correction to the detection method. That is why the classifier machine-detects vendor names. And it is why opt-out is checked first anyway. Getting a data point does not override someone asking you to stop.

Source page: https://suryapugaz.com/special-stage/the-stage