← All posts
SHELVED · COMPANION TO CASE STUDY

663 sends. 0 replies.

A productized outbound stack — sequence engine, enrichment, reply classifier, dashboard — pointed at the audience I knew best. Infrastructure was working. The wedge wasn't. The fix is a fifty-name test that runs before any build.

2026-04-30·5 min read

The infrastructure shipped. The sequence engine rendered steps and branched on conditions. The enrichment pipeline returned structured records. The dashboard let me edit a lead’s state in place and watch the sequence respond. Deliverability held. Opens came in at a plausible rate. Clicks came in at a thin but real rate. Six hundred and sixty-three messages went out across a clean sequence.

Replies did not come in at all. Not one.

The full story is the SalesBot case study. What follows is the rule I now run before any outbound system gets built.

Two unknowns, only one of which the stack solved

Cold outbound has two unknowns wired in parallel.

The infrastructure unknown is whether you can deliver at scale. Sequencing, deliverability, enrichment, reply handling, the operator dashboard. This is solvable in weeks by any competent operator with a recent stack to copy from. It’s the unknown that feels like the project, because it’s the part that produces visible code and visible commits.

The wedge unknown is whether anyone actually wants what you’re offering, written the way you’ve written it, sent to the audience you’ve targeted. This is the harder unknown, by an order of magnitude, and it’s almost always solved last — which usually means it’s solved by the market, in production, after the build has shipped.

I solved the first unknown with the SalesBot stack. The second unknown was answered by 663/0. Not gradually, not noisily — unambiguously. The market was telling me the offer, written that way, did not move the people I’d targeted. No subject line variant or send-time tweak survives that reading honestly.

The expensive lesson was running the validation experiment with the validation experiment’s hypothesis carrier (the stack) treated as the hypothesis. The stack worked. The hypothesis didn’t.

The discipline that should have run first

Before any productized outbound stack — and before any cold outbound at all on an unproven offer — I now run a fifty-name test. Half a day of name-picking, an hour of writing, one week of manual sending. The cost of running it is trivial; the cost of skipping it is whatever the build costs.

The shape:

Pick fifty names by hand. Not a sample from a vendor database. The fifty people in the world most likely to respond if anyone will. The warmest version of your buyer profile, the people whose match is so close that a “no” from them is real signal. If picking these fifty takes more than half a day, you don’t yet know who your buyer is — that’s a finding, not a delay.

Write the offer in plain language, before sending anything. One paragraph. Specific. Names a problem the recipient actually has, in the language they’d use. Proposes something concrete and finite that’s valuable on its own — not a sales call. Closes with explicit permission to ignore.

Send manually, plain inbox, no automation. No sequencer, no tracking pixels, no personalisation tokens, no CRM. Open your normal inbox, type the message, send. The recipient should feel they got a personal email, because they did. All fifty within one working week.

Decide before sending what counts as a positive signal. Substantive replies — engagement with the substance of the offer, clarifying questions, accepting a next step, declining specifically. Polite “let’s circle back” doesn’t count. Opens don’t count.

Decide before sending what each outcome means. Zero substantive replies on fifty: stop, don’t tune the message, the offer or the audience is wrong. One: noisy, run another fifty. Two to three: real signal, worth investing more. Four to six: strong signal, build the delivery infrastructure. Seven or more: either the offer is exceptional or the fifty were too warm — validate against a colder fifty before shipping.

The decision rules are non-negotiable. The point of the test is the rules; the messages are just how the rules get exercised.

Why this works

Cold outbound at scale is a delivery problem. Cold outbound at zero scale is a wedge problem. Different shapes, different costs, different rates of success. The fifty-name test isolates the second from the first. It decides whether the next eighteen months of build is worth starting.

The stack you’d build to scale a wedge that works can be assembled from existing components in weeks. The stack you’d build to scale a wedge that doesn’t work is the same stack — and the months of effort, the deliverability warm-up, the infrastructure tuning, all become the storage area for a confusion about what was supposed to be tested.

A fifty-name test cleanly separates the layers. If the offer doesn’t move fifty hand-picked names, no automation in the world will save it. If it does move them — even moves two or three — the build now has a real mandate, and the stack is no longer the experiment but the amplifier of an experiment that already returned a positive result.

What I now do differently

The fifty-name test runs before any build. Always. On every project where the question is “does this resonate with this audience” — outbound, content, product positioning, advisory pitch — the same shape applies. Pick the fifty, write the offer, send manually, read the substantive replies.

The outbound campaign I currently run — the one that actually works, the one with the eight production incidents resolved and the daily cadence in business hours — is what shipping looks like when the wedge has been validated. The build looks similar. The reception is unrecognisable.

Same delivery infrastructure. Validated wedge. Different result.

← NEWER

Two stress tests most operators skip

OLDER →

The whitepaper is the contract