Skip to content
~/robynrocha.io
cd /home
Case studyOutbound / Deliverability / Messaging

Cold email, run like a factory

Two layers do the work: a message system that resolves strategy before anyone writes, and a sending fleet that lives on its own clock. Between them sits the one irreversible act in the whole program — the click — and everything is arranged to make that moment boring.

This is the send side end to end: what gets written, what it is written against, what carries it, and the checks between a finished pack and a live campaign.

[ Why Build Any of This ] No platform runs the program for you

It is fair to ask why any of this needs building. The honest answer is that no single tool ships a cold outbound program — they each solve one slice and hand you the rest.

Transactional platforms exist for receipts and password resets; mailbox providers treat that traffic differently and punish you quickly for pointing one at prospecting. Sequencers are built around a rep's own inbox for one-to-one selling, so volume concentrates on a single domain — precisely what collapses deliverability at scale. Cold email platforms are the closest fit, with multi-domain sending and warm-up built in, but they still hand you an empty campaign builder and wish you luck.

Nobody ships the targeting, the message system, the fleet discipline, or the reply handling. That gap between "the platform can send" and "the program runs" is what everything below fills.

[ The Factory ] Describe a campaign in a sentence, get a validated upload

What it is: a staged, deterministic pipeline run in Claude Code — not a vague "AI agent" freelancing through the task, but a defined sequence with checkpoints. Describe a campaign in plain English and the system pulls matching companies from the pre-scored database, checks the CRM for customers and open deals, finds the right people, matches each company to a pitch that has already won customers, and writes a unique email for every person with about twenty AI writers in parallel. Every email is validated for banned words, length, and accuracy before upload.

Why it's built this way: a human approves at two points — the play assignments and the sample emails — and the do-not-email rules run at three separate stages and cannot be skipped. That is the difference between "AI helps with email" and "AI can be trusted with the send button." Turnaround goes from days to same-day.

$render campaign-factory.mmd

No diagram code provided

rendering diagram…

[ The Philosophy ] Every message should only make sense to the person reading it

What it is: two honest modes, kept separate on purpose. Trigger-based outreach is templated deliberately — the trigger already did the personalization work. Cold email to a list is the opposite: every email assembled from several independently-prompted lines, each fed by a different public data point, composed into one message that wouldn't make sense sent to anyone else.

Why it's built this way: a model that only has to nail one sentence, fed one clean variable, writes a much better sentence than a model improvising a whole email. It's how personalized advertising already works — assembled from what's known, not written generically — and cold email built on public firmographic data can work the same way.

$render modular-line.mmd

No diagram code provided

rendering diagram…

[ The Message ] Strategy resolves before a word gets written

What it is: a six-stage chain. Strategy decides the play, the positioned offer, the angle, and the persona posture, then sets a specificity dial — how much per-account detail a message should carry. Segment turns those directions into copy slices, each with a record of exactly which decisions produced it. Craft writes the pack against that record. Defend hardens it. A handoff manifest hands two artifacts to the send side. Recover is the branch that runs when something stops working.

Why it's built this way: most cold email is written before anyone has decided what it is arguing. Resolving the play and the offer first means the writing step has a real brief instead of a vague target, and every finished variant can be traced back to the decision that caused it. The offer itself is positioned here, never invented here — that is a business decision, not a copy decision.

$render messaging-chain.mmd

No diagram code provided

rendering diagram…

[ Fingerprint Defense ] A template is a pattern, and patterns get matched

What it is: the pack that reaches the sender is not one email. It is a pool of subjects, a pool of structural skeletons, a map of which variables fill which slots, and a rotation plan — with each variant carrying its own lineage so a result can be traced back to the exact skeleton, spin, and word-level choices that produced it.

Why it's built this way: filters do not evaluate your email, they evaluate the pattern across your whole list. Defense is structural first: genuinely different skeletons beat synonym-swapping inside one fixed shape. Word-level hygiene sits underneath as a floor, not a strategy — the aim is a message that does not share a shape with the other ten thousand, rather than one that dodges a keyword list.

Lineage is the part that compounds. When a variant burns, the failure is attributable to a surface instead of a vague sense that "the copy stopped working."

$render fingerprint-defense.mmd

No diagram code provided

rendering diagram…

[ The Stack ] The tools, and why those tools

What it is: Claude Code is the surface; the platforms are the backend. That only works when the sending platform is API-first — everything the UI can do, the API can do — with webhooks that fire for replies, bounces, and disconnections the moment they happen. PlusVibe earns its seat with one thing the others don't have: it runs its own warm-up pool, native to the platform rather than rented as an add-on. EmailBison is the other platform that passes the test.

Why not the alternatives: SmartLead's webhooks silently dropped replies — fatal when the reply pipeline depends on catching every one — and its per-lead pricing punishes pointing a real CRM at it. Sales-engagement platforms are a different category entirely: built around a rep's own inbox, not dozens of dedicated sending domains.

The bench around the sender: sequencers Lemlist, Supersend, Heyreach, and Quickmail for the plays a different surface fits. Inbox supply from InboxKit, HyperTide, ScaledMail, and Maildoso, so mailbox capacity is never the bottleneck; HotHawk and RevReply on inbox management. EmailGuard carries placement tests and domain health, with GlockApps, Warmy, and MailReach as the monitoring bench.

$render stack.mmd

No diagram code provided

rendering diagram…

[ The Fleet ] The sending asset runs on its own clock

What it is: domains and inboxes are a standing asset with a lifecycle that has nothing to do with any particular campaign. Capacity is sized from the daily send target and a budget ceiling, domains are registered and authenticated, inboxes are connected and dressed with a consistent identity, then warmed — stock drawn from providers like InboxKit, HyperTide, ScaledMail, and Maildoso. A human gate decides when stock is actually ready — warm score and inbox placement both have to clear, not one or the other. Health is watched continuously, and a reserve rotates in as stock degrades.

Why it's built this way: treating the fleet as campaign infrastructure is how programs die. Warm-up is the long pole in any launch, so the fleet has to be built ahead of demand rather than in response to it. Keeping the fleet on its own clock means a campaign draws from ready stock instead of waiting on provisioning — and a burning domain gets rested before it takes a campaign down with it.

Catch-all addresses get their own isolated lane — separate domains, separate inboxes, a dedicated tag — so that a riskier class of address can be worked without putting the main sending reputation behind it.

$render sending-fleet.mmd

No diagram code provided

rendering diagram…

[ Assembly and Pre-Flight ] Built paused, read by a human, then clicked

What it is: the list is verified and routed, the campaign is assembled paused, its configuration is read back off the wire to confirm what was actually stored, and every toggle is set from a reasoned matrix rather than left at whatever the platform defaults to. Then a placement spread is gathered and a person reads it before anything sends.

Why it's built this way: the click is the one irreversible act in the whole system. Everything before it is arranged so that the moment is boring: nothing is assumed to have saved correctly, one specific setting that would let a campaign blow past per-inbox limits is pinned off permanently, and the spam-word scan advises rather than blocks — relevance beats keyword avoidance, and an automatic hold on a false positive costs more than it saves.

No single placement tool gets crowned. A spread is gathered from what is available and a human reads the spread, because every seeding method has a blind spot and a clean score can sit on top of a silent problem.

$render assembly.mmd

No diagram code provided

rendering diagram…

[ When It Burns ] A verdict routes to a surface, not to a shrug

What it is: when the live watch confirms something is genuinely wrong — as opposed to a bad morning — the verdict routes by cause. A word-level problem goes to hygiene. A worn-out structure goes back to the variation program for a refresh. An argument that is not landing goes back to Strategy, or up to the business if it is the offer rather than the angle. A production defect goes back to Craft. Infrastructure trouble goes to the fleet, not the copy.

Why it's built this way: the default failure mode in outbound is to change everything at once and learn nothing. Routing by cause is only possible because each variant carried its lineage, and a recovered campaign re-enters through the normal chain as a new campaign with fresh checks — not as a quietly resumed old one.


The rest of the system: Running the Seat · Data & AI Infrastructure