DEV Community: Axel Freeman

A marketing playbook is the second step — almost nobody asks for it at the right time

Axel Freeman — Tue, 22 Sep 2026 15:31:08 +0000

Every week someone asks me for a marketing playbook. Almost nobody asking has a working hypothesis yet.

That is the problem, and it is worth being blunt about it: a playbook is the second step, never the first. Compiling one does not move you closer to sales. It is what you write after something works.

What a playbook actually is

A written set of client-acquisition moves that already work — simple, primitive, repeatable:

Bought an ad from a blogger in segment A — it produced clients.
Segment B gave the numbers in three months.
This targeting converts a client at break-even or better.

One proven move, one line. Not a strategy deck, not a framework, not "our methodology". Instructions somebody can follow next Monday.

You build it yourself, by hand, or with your two or three closest people. Nobody hands it to you — a borrowed playbook is a wish list.

Why it is the second step

The order is fixed:

You find a working hypothesis by hand (for most B2B that means cold outreach, free).
You press it until you know where its ceiling is.
Only then do you write it down — and what you write down is the playbook.

A playbook assembled before step 3 is a notebook of guesses, and the most expensive way to feel productive. If you have zero clients, the honest answer is not a playbook — it is that the job is still the search.

The moment a playbook changes anything

Written down, the working moves stop being founder-only knowledge. They can be handed to a marketing hire, a department, any person who follows a procedure — or to an agent, if the work is genuinely repeatable.

This is where the mode changes. Search is free exploration: hunt, guess, try the strange thing. Once you delegate a proven move, you leave free search behind and switch to regular management — goals, volume, cadence, reporting. Draining a hypothesis to the bottom is not an exploration task, it is an operating task, and it needs the basics of regular management to survive contact with a schedule.

The critical mass is around six working hypotheses. At roughly six proven, repeatable moves there is something real to hand over, and you can hire marketing. Before that there is nothing to delegate — you would be hiring someone to keep guessing, which is what you were already doing.

The part people get wrong: failed hypotheses

A negative result gets one line in the archive: what was tried, and that the numbers were zero. Nothing more.

Two practical reasons.

There is nothing to learn from a zero. Marketing — especially the first-clients stage — is not a mathematical craft yet. A zero does not tell you which variable was wrong, because you usually changed five things at once and the market did not answer.

Handing a new person your failures is toxic. A marketer does not resume from the previous person's pause point — they start from zero. Old data genuinely gets in their way, and failed old data gets in the way worst of all. You will spend their first month arguing about a channel that died for reasons that no longer apply.

Keep negative experiments as historical context for whoever asks (an agent, a new hire) — a separate record, never a starting point.

Try it as a command

With the npm package installed:

npx marketing-mindset playbook --hypotheses 0
# stage: search    -> no proven move; the job is still the hunt

npx marketing-mindset playbook --hypotheses 3
# stage: draining  -> write them down and press each to its ceiling

npx marketing-mindset playbook --hypotheses 7 --written
# stage: delegate  -> there is something real to hand over; hire marketing

The one-line version

Find a working move by hand -> drain it -> write it down -> delegate it.

Full write-up with the rules and the archive policy: What is a business sales and marketing playbook?

The whole mindset is open source (MIT) and installable as an agent skill: https://github.com/axelfreeman/marketing-mindset

Your B2B list is worth its address share, not its row count

Axel Freeman — Sat, 19 Sep 2026 10:16:23 +0000

A 10,000-row list is not 10,000 chances to get a reply. It is however many of those rows publish an address on their own domain — and that second number is a property of the source, not of the file. We keep a working file of company domains and count that share for every source family we pull from. Here is what it looks like after 9,756 domains, 1,714 public addresses and one honest question: where did the domain come from?

Two ways to get a domain, and only one of them is clean

A domain can be read out of text where someone mentioned their company, or read out of a field the company itself filled in a directory. The second one is cleaner by construction.

On a job board the domain has to be dug out of the vacancy body. Roughly half of those attempts land on the job board itself, on a recruiting platform, or on a company already in the file. On an application marketplace or a package registry the domain is a named field filled by the vendor, and the reject rate drops to single digits.

Our largest single pass came from an application marketplace: 3,000 applications → 2,377 new domains → 1,798 live sites with product signals (76%) → 1,538 rows kept (65%). The filter that did the cutting was not a blacklist but a product test: pricing, a sign-up, a demo request, integrations. Documentation sites, personal pages and framework homepages go out there.

The field that gave the domain gave nothing else

Those 1,538 rows came with an address share of zero. The field is a website, not a contact. We had grown the file by 1,538 rows and the number of sendable rows by nothing at all — which is exactly the trap of measuring a campaign by file size.

So we stopped counting domains and started walking sites.

300 "contactless" rows, walked

We took 300 rows with no address and opened the pages companies publish for contact: home page, /contact, /about, an imprint page where the law requires one. Only addresses whose domain matched the company's own domain were kept.

Step	Result
Rows walked	300
Domains with a published address on their own site	172
Kept after the address-to-domain rule	169
Answering MX	169 of 169
Spot-check against the live page	4 of 4 confirmed

A source that looks contactless at intake is more than half contactable if you read the pages the company actually maintains. The three rejected addresses are the other half of the rule: one mis-split token and two strings that only looked like addresses in raw HTML. They were dropped, not repaired. An address that has to be guessed is not a contact.

Yield by source family

Where the domain came from	Domains taken	Live with product signals	Rows kept	Publish an address
Application marketplaces (vendor-filled `external_url`)	3,000	1,798 (76%)	1,538 (65%)	0% at intake → 56% after walking contact pages
Agency directories	59 hosts per pass	full pass	492	~60%
Package registries (`projectUrl`, `homepage_uri`)	3,821	140 (29%)	140	~15%
Repository `homepage` (GitHub repos and orgs)	2,429	553	553	~11%
WordPress.org (plugin homepage, theme author URL)	9,785	600 of 695 themes	486 plugins + 490 theme authors	~34% for theme authors
Job-description text (boards, "who is hiring")	~1,100 vacancies	–	8 of 16 confirmed	half the rows never reach the contact step

Theme authors sit in between, and for a reason: 8,695 themes in the WordPress.org directory resolve to 729 unique author domains, and a theme shop is a company selling a product, so it publishes pricing, support and a contact page — 600 of 695 answered, 490 were kept, and a third of those handed over an address.

That table is the whole argument. A vendor who sells you 10,000 rows is selling you the left column; the column that decides whether the list is work or decoration is the right one. At 11% the same file is 1,100 addresses, at 56% it is 5,600.

How each row is counted

Domain from a filled field. No row enters without a domain that belongs to the company and a URL where it was published.
Live site with product signals. A 200 is not enough: pricing, sign-up, demo request or integrations must be present.
Address matched to its own domain. A role address on someone else's domain is not a contact for that company, however it appeared on the page.
MX before sending. Every address domain answers MX; the ones that do not are marked, not hidden.
The reject reason is kept. Removed rows stay in a reject file with the reason, which is how the numbers above can be checked.

Three questions for a list vendor

What share of rows publish an address on their own domain — not "has a contact field"?
How many domains answer MX, and what happened to the ones that did not?
Which addresses came from a field the company filled, and which were assembled by a tool?

A vendor who cannot answer the third question is selling the 0% column. Building the file is not romantic work; it is counting, and then walking the pages.

The full method, the checks and the numbers are on the site: The address is the only number that matters in a B2B list — that page also carries the six list checks and the pre-send audit, in case your file is fine and your sending is not.

Deliverability is a list problem before it is a sending problem

Axel Freeman — Sat, 19 Sep 2026 09:56:10 +0000

Most outbound teams I look at have bought their infrastructure before they have looked at the list. Domains, mailboxes,
warm-up calendars, sending tools, a spreadsheet of sequences. The list — the thing that decides whether the first day of
a campaign produces replies or complaints — is checked last, if at all.

Authentication is the cheapest check in the stack: SPF, DKIM, a DMARC policy, a live address for the aggregate reports.
Google and Yahoo made it a requirement for bulk senders rather than a competitive edge, together with a complaint rate
under 0.3% and one-click unsubscribe. An afternoon of DNS work, and it is done.

After that, the failures stop announcing themselves. They arrive as bounces, as complaints, as a reply rate that looks
like a market problem but is a list problem.

The nine checks, in the order that removes risk

SPF and DKIM alignment — both records exist and the sending domain matches the From domain.
DMARC policy and reporting — a published policy with reports going somewhere a person reads.
Tracking-domain separation — clicks are rewritten to a CNAME on your own domain, not a shared vendor host.
One domain, one purpose — cold outreach, marketing and transactional mail on separate subdomains.
Root-domain folding — everything folded to the registrable domain before counting, or one company appears four times as www, as app, as a regional subdomain and as the root.
MX check per domain — a domain with no mail exchanger cannot receive the email being prepared for it.
Address-to-domain match — the address must belong to the domain it is filed under. This is the check that removes hello@world.com and addresses lifted from another company's page.
Role and pattern rejection — info@, support@, noreply@ separated rather than sent to.
Suppression and send caps — unsubscribes, bounces and previous non-replies subtracted before the batch is built, and a per-domain cap so the same company is not hit twice in a week.

What the numbers look like

These are our own prospecting numbers, not a client's. The working file holds 9,266 company domains, refreshed
19 September 2026. 1,358 of them carry a public address at all — 15%. Behind those addresses sit 1,358 domains, of
which 1,350 answer an MX lookup. The eight that do not would have gone out as part of a "verified" list.

The gap between 9,266 and 1,358 is the part people skip. Domain count is a sourcing metric. Address count is a sending
metric. They differ by a factor of seven.

Where the rows come from matters more than how many

Same checks, same budget, four source families, and the share of kept rows that carry a public address:

agency directories — 60%
package registries (NuGet, RubyGems, npm) — 15%
GitHub repository homepages — 11%
hiring feeds (Arbeitnow, HN Who is hiring) — 11%

An agency site is built to be contacted. An open-source project page links GitHub, not a sales team. The extraction rule
is identical in all four cases — take the domain from the post, never from the text — so the difference is the source,
not the method.

Yesterday's run added a new family to the file: application marketplaces. The Zapier directory exposes each app with a
structured vendor URL, which makes it the cleanest version of the rule so far. 3,000 applications gave 2,377 domains
that were not already in the file, 1,798 of them answered with a live site showing at least two product signals (76%),
and 1,538 survived once the threshold went to three signals (65%). That single pass was larger than any directory gave
us in a day — and it is also the weakest family on contacts, because the field is a website, not a mailbox.

The audit is a set of files, not an opinion

What comes out: an authentication report per sending domain, an MX report, three reject files (no MX, address-domain
mismatch, placeholder or role), a send plan with batch sizes and caps, a suppression list, and one call on the numbers.
Nothing in it is a promise about replies. A clean list removes bounces and complaints; whether a segment replies is a
question about the offer, and that is what a pilot is for.

The nine checks are written out, with the measured yields and the reject files, here:
Cold email deliverability audit — nine checks before the first send.

The reject file: every row my B2B list threw away, and the check that killed it

Axel Freeman — Sat, 19 Sep 2026 09:30:20 +0000

The reject file: every row my B2B list threw away, and the check that killed it

A list is usually sold by what is in it. This is a post about what came out of mine, and why — because the count that
survives the checks is the only number you can audit, while "100% verified" is a number you can only believe.

I keep one working file for outbound segments. As of today it holds 7 728 company domains collected from
49 public sources, of which 1 381 publish an address of their own (18%), and 1 350 of the 1 358 domains behind
those addresses answer an MX lookup right now. Everything below is counted from that file, not estimated.

The rule that decides everything: where the domain comes from

Before any technical check, one sourcing rule does most of the work. A domain enters the file only if it sits in a field
the owner filled in about itself:

a company directory's website field,
a package's projectUrl (NuGet) or homepage_uri (RubyGems), homepage (npm, crates.io),
a repository's homepage field,
a launch post's canonical URL.

A domain dug out of the body of a job ad or a sentence in a post is inferred, and inference is where invented
addresses come from. Job feeds are the clearest example: the vacancy mentions the employer, a customer, an ATS and a
cloud host in the same paragraph, and half the candidate domains have to be thrown away by hand. Hiring threads yield
addresses about 11% of the time. Package registries, the same idea one ecosystem over, yield 15%. Agency and
SaaS catalogues yield 60%.

The six checks, in this order

Domain from a structured field. As above. No field, no row.
Fold to the root, then de-duplicate. blog., app., shop. and demo. subdomains collapse into one company, otherwise a single vendor arrives as four rows. After folding: 7 728 rows, 7 728 unique domains, zero rows without a domain.
Fetch the host live. Not answering 200 on HTTPS and then HTTP means it is dropped — parked domains and dead projects included. Cheapest filter, biggest pile of removed weight.
Does the site behave like a product company? At least two of: pricing or plans, sign-up or free trial, a "book a demo" or "contact sales" path, integrations or API documentation. This is what keeps blogs, documentation sites and academic pages out of a B2B segment.
Does the address belong to the domain it sits on? Addresses are kept only when the mail domain matches the site they were found on, or a subdomain of it. Agency catalogue pages publish third-party addresses and placeholders like hello@world.com often enough that this check is not optional — a row with someone else's address is a complaint scheduled for later.
Does the domain answer for its mail? An MX lookup. Of the 1 358 domains behind published addresses, 1 350 answer and 8 do not; those rows are marked and kept out of batches rather than counted as contacts.

What each family yields, measured instead of claimed

Family of sources	Rows	Published an address	Yield
Agency and SaaS directories	876	522	60%
Company directories (YC dump)	548	265	48%
Package registries	328	50	15%
Launch feeds and product posts	745	88	12%
Hiring threads and job feeds	4 012	432	11%
Repository homepage fields	553	59	11%

Two things only show up because the table is published.

First, the ecosystems are not comparable. Directories built for selling arrive with the contact already on the page;
hiring feeds are written to attract candidates, not to be harvested.

Second, a structured field is a guarantee about the domain, not about the contact. Repository homepages come from a
field its owner filled in and still yield 11% — a package registry's projectUrl yields 15%, an agency directory 60%.
If you buy rows by the thousand, the family they came from is a better predictor of what reaches a human than the word
"verified" on the invoice.

The reject file

What fails is not deleted. It is written out with a reason column, so the count can be audited instead of trusted, and
it comes in three parts:

Dropped at sourcing — the domain was not in a structured field, or the host never answered.
Dropped at the product test — the site behaves like a blog, a docs site or another directory rather than a vendor.
Dropped at the mail test — no MX, or an address belonging to a different domain than the page it was found on.

The reject file is handed over with the segment. A batch is built from the working file, and a row that is not in the
file is not in the batch — no purchased lists are mixed in, because a purchased row has no source column to audit.

What I do with this

I build outbound segments for SaaS teams, agencies and local B2B companies, and the reject file is part of the
deliverable. The checks above, the yield table, and the three reject lists are published on
the verification page,
together with the current numbers of the working file. If you want the same six checks run against a list you already
own, that is the fastest way to find out whether it is worth sending at all — and the
scopes and prices
are published the same way: $900 for the fourteen-day pilot, $1 900/month for the ongoing engine, $2 900 for the full
build.

One line to take away, whether or not you hire anyone: measure a list by what it throws out. The proportion that
survives six checks is a fact about the file. "Verified" is a fact about the seller's confidence.

The fourteen days of an outbound pilot, written down before you pay

Axel Freeman — Sat, 19 Sep 2026 08:58:35 +0000

The fourteen days of an outbound pilot, written down before you pay

Most pilots are sold as a wager: give us money, give us a month, and we will see what happens. The wager is not the
problem. The problem is that nothing in the arrangement lets you check the work while it is being done, and nothing in
the read-out lets you tell a bad segment from bad copy. So here is the pilot I run, day by day, before anyone pays for
it — and the numbers each day actually produces.

Days 1–3: where the domain comes from

A segment is only as honest as the field the domain was read out of. That is the rule I hold to, and it is stricter
than it sounds: the domain has to sit in a field its owner filled in, not be extracted from prose.

The best version of that rule is a package registry. A library's projectUrl on NuGet or its homepage_uri on
RubyGems is written by the vendor about itself, and it is machine-readable, which means it can be audited rather than
trusted. The last pass over two registries looked at 483 candidate domains and found 138 live sites that passed a
product test (pricing, a signup path, a demo request, integrations) — a 29% survival rate.

Compare that with a job feed, where the company domain has to be dug out of the body of a vacancy. On hiring threads
the same pipeline yields about 11%. The rows are not worse because job posts are dishonest; they are worse because the
domain is inferred rather than declared. Inference is where invented addresses come from.

The working file now holds 7,641 company domains from 48 public sources, and 1,355 of them publish an address
(18%). That last number is the one I would want if I were buying: the majority of companies with a live product site do
not publish an email address on it, so a list sold as "100% verified" is either smaller than claimed or has been
completed by guessing.

Days 3–5: verification, and what is handed back

Verification is not a single check. It is a sequence, and each step drops rows:

Domains folded to their root, so a blog or an app subdomain does not become a second company.
Duplicates collapsed on the root domain, not on the string.
Rows without a domain dropped outright — no domain, no row.
Each host fetched live. A 404 is a dead company, not an unverified one.
Each address matched to the domain it claims to sit on. hello@takt.com on the page of taktstudios.ca is not an address for the company on the page.
An SMTP check before anything is sent.

What does not survive is not deleted quietly. It is handed over as a separate file with the reason attached: which step
dropped the row, and what the row looked like when it went in. An agency reselling this needs that file more than it
needs the good rows, because it is the only way to explain to a client why the count changed.

Days 5–7: the domain that is not the main domain

Sending happens from a separate domain, warmed in the open, with SPF, DKIM and DMARC in place. This is the part of the
pilot that is deliberately not clever: if deliverability is going to be damaged, it gets damaged in a domain built for
outbound, never in the one the company answers email on.

The infrastructure is the deliverable here, not a service you rent forever. Records, warm-up history and the sending
domain stay with the client at the end of the fourteen days.

Days 7–14: one batch and a read-out that does not flatter

One segment, one batch, replies worked as they arrive. The read-out counts replies and conversations. It does not count
opens, and it does not report an "engagement rate" assembled from pixels.

It also does not promise meetings. A pilot is a measured test: if the reply rate is zero, the read-out says zero and
then says which family the segment came from, how many addresses survived the SMTP check, what was delivered and what
bounced. A zero with a reason beats a promised pipeline with none, and it costs less to find out.

What the pilot is not

Not a guarantee of meetings. Reply rate depends on the segment and the offer, and it is measured rather than assumed.
Not sending from your main domain.
Not a scraped list with invented addresses.
Not a retainer in disguise: fourteen days, one batch, one read-out, then a separate decision.
Not a channel that reads your inbox — replies arrive at an address you can see at any time.

What you hold at the end is a verified segment with its source column intact, a warmed domain in your name, the copy
that went out, and the method. That is the deliverable. Meetings are the outcome, and they are earned rather than
promised.

The pilot is published at $900, written down day by day, here:
the $900 outbound pilot.
The three scopes and prices are on pricing,
and the sourcing rule behind the numbers is described in B2B lead list building.
The Telegram link on any of those pages is prefilled if you want the first segment priced.

White-label lead generation: an agency should buy capacity, not lists

Axel Freeman — Sat, 19 Sep 2026 08:42:20 +0000

White-label lead generation: an agency should buy capacity, not lists

Every agency I have watched buy data has bought the wrong thing. Not a bad list — the wrong unit. A list is an
inventory purchase: you pay for rows, you discover on the first send which ones were real, and the discovery cost
arrives as bounces on a client's sending domain. Capacity is a different unit of purchase. You buy a production run
with a known failure rate, and the failure rate is measured before the send.

That distinction is the whole partner conversation, and it is countable, so let me count it.

The file this is built on

Working file as of 19 September 2026: 7,503 company domains collected from 46 public sources, of which
1,305 have a public address on the company's own pages or in the listing itself. The file was assembled with one rule that decides everything downstream:
a domain comes from a structured field — an API website field, a hiring post's own URL, a catalogue's outbound
link — never from the body text of a post. A row without a domain is dropped rather than guessed.

The second rule is that nothing ships unchecked. Every host gets requested live and has to answer with product
signals (pricing, signup, demo, trial) before the row stays. Every address has to sit on the domain it claims. The
address is SMTP-checked before the send. In practice that pass removes roughly a third of a purchased list — and
agencies keep asking me to leave that third in, because a bigger number looks better in a proposal. It does not
look better three weeks later.

Yield by source family is the number that matters

Different source families fail at very different rates, and that difference is what an agency should be buying on:

Source family	Rows kept	With a published address	Yield
Agency directories	492	492	100%
Hiring threads ("Who is hiring", 2024 → Sep 2026)	2,792	304	11%
YC company directory (website field)	548	265 (pulled from the companies' own pages)	48%

Agency directories come in at 100% because the listing itself publishes the contact row — the directory's business
model is publishing an address. Hiring threads sit at 11% because a job post carries a domain and no mailbox; you
get a company to research, not a person to write to. The YC directory gives 548 valid companies in a single pull and ships no contact field at all — the 265 addresses
below that line were collected afterwards from those companies' own pages, which is exactly the shape of a source you
use for reach first and contactability second.

If an agency is buying volume by the row, it is buying the 11% column and calling it 100%. That is the entire reason
white-label production runs beat list purchases: the yield is measured per family, before the client sees anything.

What a partner run actually contains

The four steps are the same whether the end client is a SaaS company, an agency's client, or a local B2B:

Segment from public structured sources. Families above, with the source column preserved so a later audit can answer "where did this row come from" without asking me.
Verify before anything is sent. Live host check, address-to-domain match, SMTP check, and a separate file for what did not survive — so the count change can be explained to the client instead of hidden from them.
Send under the agency's brand. Sending domains, mailboxes, throttling and warm-up belong to the client relationship, not to the vendor. Copy is written to the segment; the reply loop is worked, not just opened.
A read-out that can be forwarded. Sent, delivered, replies, positive replies, booked conversations, per segment, with the raw rows attached as CSV and JSON.

Nothing in that list is exotic. The part agencies actually buy is that all four are already built and measured, so a
client promise that needs 2,000 more touches this month does not require hiring or a migration.

The pricing model, published

This is the part that usually stays hidden behind a "book a call" button, and it is the reason this post exists:

$900 — one-off Sprint: one segment, verification pass, copy, sends, first read-out.
$1,900/month — Engine: a monthly loop, new segment each cycle, replies worked, forwardable read-out.
$2,900 — Full Build: the machinery as the deliverable, handed over so an in-house team runs it afterwards.

These are the cost basis for a white-label run, not a reseller licence fee with a markup ladder on top. An agency
invoices its client at its own price; the margin between that and the cost basis is the agency's, and there is no
separate "partner tier" priced above the public number. Exclusivity is per vertical and per sending domain, agreed in
one line before the first run, because the sending domain is the part that actually collides.

The uncomfortable honest part

Bounces are not a guarantee anybody can make. They depend on the sending domain, the daily volume and the age of the
row. What can be guaranteed is the method: check before the send, match the address to its own domain, feed every
bounce back into the file. An agency that has been sold a bounce-rate promise has been sold something the vendor does
not control — and when it fails, the agency is the one standing in front of the client.

Buy capacity with a measured failure rate. It is a smaller number and a longer relationship.

Cost basis, scope and the three plug-in modes are published here:
agency partner program
— and the engagement itself is described at
marketing engineer.
If you run an agency and want the first segment priced, the Telegram link on either page is prefilled.

I enriched 6,955 company domains. Only 1,040 of them publish an address

Axel Freeman — Sat, 19 Sep 2026 08:07:14 +0000

I enriched 6,955 company domains. Only 1,040 of them publish an address

Six thousand nine hundred fifty-five company domains, forty-five public sources, one working day. That is the
file behind this post. The number worth arguing about is not the total — it is 1,040: the rows where the
company itself published an address you can write to. Fifteen percent.

That gap is the whole business of B2B data enrichment, and most vendors fill it with the wrong thing.

Where the domains came from, and what each family actually yields

Every row in the file carries its source and the live check it passed. Counted row by row, not estimated:

Source family	Domains	Published an address	Yield
Hacker News "Who is hiring?" threads (2024 → Sep 2026)	2,792	304	11%
Y Combinator open-source hiring directory	736	0	0%
remoteintech/remote-jobs public catalog	531	0	0%
Agency directories (DAN / Semrush listings)	492	492	100%
Show HN launches — domain taken from the post URL	407	44	11%
SaaSHub category listings (catalog outbound link)	351	0	0%
WordPress plugin directory homepage fields	350	9	3%
GitHub repository and organisation website fields	466	33	7%
dev.to posts whose canonical is a company domain	220	40	18%
Job feeds (WeWorkRemotely, Jobicy, Arbeitnow, RemoteOK, Remotive)	215	92	43%
npm, crates.io and package-registry homepage fields	190	0	0%
Reddit, Mastodon, Product Hunt and HN signal threads	142	22	15%
Total	6,955	1,040	15%

Two readings matter more than the total.

Hiring threads give you companies, not contacts. 2,792 domains — 40% of the file — and 304 mailboxes,
because the post names the employer and not the person. That is the raw material an enrichment step has to work
with.

Directories give you contacts, not prospects. Agency directories publish an address for 492 of 492 rows,
because agencies put one on their own site on purpose. A list built only from job feeds is a list of companies; a
list built only from directories is a list of competitors.

What public sources can append — and what they cannot

Appendable, because it is observable:

company identity — name, root domain, and the exact page the domain was taken from;
what they sell — product category, whether a pricing page and a self-serve sign-up exist;
hiring signal — open roles and titles, the cheapest honest intent signal;
public addresses — role and generic mailboxes published on their own domain;
channel hints — blog, docs, changelog, marketplace listing.

Sold as enrichment, but not observable:

personal mobiles — not public; anything sold as such is scraped, stale or invented;
revenue and headcount — third-party estimates with no published method;
intent and "in-market" scores — a vendor model, not an observation;
technographics — guessed from headers and script tags, right often enough to be dangerous.

Once you accept that split, the pricing model of the market flips. What is worth money cannot be bought in bulk,
so it has to be observed one row at a time.

The three checks a row survives before it counts as enriched

1. The domain comes from the source, not from the text. A structured field, a post URL, a package homepage,
a catalog's outbound link. Text mining is where the junk enters: on the first pass over job feeds about half of
the extracted domains were the board itself, an ATS (greenhouse.io, lever.co, ashbyhq.com) or a link inside the ad
rather than the employer.

2. The host answers and looks like a company. Every candidate is requested live and kept only if the page
carries product signals — pricing, sign-up, demo, contact. On the SaaSHub pull this pass took 909 candidates down
to 351 usable rows. Without it the file fills with university course pages, docs sites and parked domains.

3. The address belongs to the domain it sits on, then it is checked. Domain match first, SMTP check second.
On one agency pull two addresses out of thirty-five were placeholder text and three belonged to a different
domain than the page they sat on — five rows that would have shipped as working data.

Underneath all three sits deduplication: 45 sources produced 6,955 rows and 6,955 unique root domains, no
duplicates and no row without a domain. Subdomains are folded into their root (app., shop., blog.) unless
the root is a platform — then the candidate is dropped.

Why the honest yield is 15% and not 100%

Because 1,040 addresses come from the companies themselves, not from a purchased database or a guessed pattern.
The rest of the rows are still useful: they are companies with a live site, a product and a hiring signal, and
their mailbox is a phone call or a form away. What they are not is a send queue.

That distinction is the reason the first test in the engagement is 100 verified contacts rather than a
monthly volume. A strict two-variant test needs 13,914 contacts per arm — 56 days at 500 a day. Below that
volume, the honest output is not a conversion rate; it is a reading list: which segment answers, which sentence
earns a reply, which objection comes back first.

Scopes, published: $900 Sprint (segment, checked rows, first touches), $1,900/month Engine (the loop keeps
running), $2,900 Full Build (offer, landing page, free tool, distribution). The arithmetic behind the numbers is
on the site: https://axelfreeman.com/b2b-data-enrichment-service.html

If you are staring at a file you already bought, the useful question is not "how many rows" but "how many of
these rows would survive the three checks". Usually about a third do not — and that is the finding, not a
failure.

I ran 521 Show HN launch URLs through a lead filter: 86 companies survived

Axel Freeman — Sat, 19 Sep 2026 07:22:26 +0000

I ran 521 Show HN launch URLs through a lead filter: 86 companies survived

Every "B2B lead list" problem starts with the same question: where did the domain come from? On job boards the employer's domain sits inside the body copy of an ad, which is why roughly half of what gets extracted turns out to be the board itself, an ATS, or a link in the text. Show HN is the opposite: the post has a structured url field, and that field is the maker's own site.

So I pulled Show HN and ran it through a filter. Here is the whole pipeline and every number, including the ones that did not survive.

The pull

Hacker News has a public search API (Algolia). Twelve pages of search_by_date with tags=show_hn, 100 hits per page, gave 521 hosts that came from the url field of a post — no text parsing, no guessing. Each candidate kept the HN item id as its provenance, so a row can always be traced back to the launch it came from.

Filter 1 — remove what is not a company

A launch URL is often not a company's own site: GitHub repos, YouTube demos, Medium posts, news stories, and free PaaS subdomains (*.vercel.app, *.pages.dev, *.onrender.com, and friends). After a blocklist of those, 223 of the 521 hosts were new against an existing file of 6,518 company domains. The other 298 were already known — which is itself a signal that this source is not a duplicate of job feeds.

Filter 2 — a domain is not a company until it answers

Every host was requested live, and kept only if it answered 200 and the page looked like a product rather than a document: pricing, sign-up, "get started", a demo link. That left 112. The 111 that dropped out were mostly one-page demos, portfolios, and blog posts about a tool rather than the tool.

Filter 3 — the subdomain trap

This is the step I would keep even if I deleted every other one. A launch URL is frequently a page, not a domain:

app.oghmere.com, shop.lumnika.com, demo.plutus-cloud.com → three rows for what is one company each
blog.codacy.com → a content subdomain of a company already in the file
what-are-you-working-on-62u6b.reachpad.app → an app instance on someone else's PaaS, not a company domain at all

Normalising to the registrable domain and re-checking the root took 112 → 105 unique candidates → 86 that answered 200 at the root. Nineteen were deep links whose root did not carry the product signals, and a handful were PaaS subdomains with no company behind them.

What the file looks like now

The filter above is one source family in a file I keep building from public sources only. Current state, counted row by row:

Source family	Domains	Publish an address	Yield
Hacker News "Who is hiring?" threads (2024 → Sep 2026)	2 792	304	11%
Y Combinator open hiring catalog	736	0	0%
remoteintech/remote-jobs public catalog	531	0	0%
Agency directories	525	522	99%
GitHub repositories and organisations (website field)	466	33	7%
Show HN launches (domain from the post URL)	407	44	11%
WordPress plugin catalog (homepage field)	350	9	3%
dev.to posts whose canonical is a company domain	220	40	18%
Package registries (npm, PyPI, crates.io)	190	0	0%
Hacker News other threads	106	22	21%
Job feeds (WWR, Jobicy, Arbeitnow, RemoteOK, Remotive, LaunchingNext, Working Nomads)	182	62	34%
Reddit and Mastodon threads	58	0	0%
Product Hunt launches	37	4	11%
Applicant tracking systems	4	0	0%
Total	6 604	1 040	16%

Two numbers in that table are worth more than the total:

Directory rows publish an address 99% of the time. Hiring threads do it 11% of the time. A hiring post gives you the company, not the contact.
Only 16% of rows publish an address at all. The rest are either checked one by one over SMTP or left out of the send queue — which is the actual cost of outbound, and the reason a list is an input rather than a product.

Why this is a lead-generation post and not a data-hoarding post

Collecting domains is the cheap half. The expensive half is what happens after: four checks before a row is ever sent (domain from the post, host answers live, published address matched to its own domain, mailbox checked where it will be used), then the volume question. A strict two-variant test needs 13,914 contacts per arm — 56 days at 500 a day. Below that, the honest output of outbound is not a conversion rate, it is a reading list: which segment answers, which sentence earns a reply, which objection comes back first.

Anyone quoting appointments per month before the segment has been read is quoting the report, not the meetings.

If you want the list, the checks and the sending run owned by someone else: appointment setting, scoped at $900 / $1,900/month / $2,900. The full source table and the four checks live on the canonical page for this article: appointment-setting-service.html.

I collected 6,032 B2B company domains in a day. Only 998 publish an address

Axel Freeman — Sat, 19 Sep 2026 06:40:10 +0000

I spent one working day collecting B2B company domains from public sources. Not "scraping the web" — 41 specific sources, each one a place where a company published its own link, and each row carrying the source it came from.

The file ended at 6,032 company domains. Of those, 998 publish a contact address of their own.

That ratio — one address per six companies — is the number nobody puts on a sales page, and it is the only one that decides whether a list is worth buying.

The yield of every source family

All numbers below are counted from the file, one row at a time.

Source family	Domains	Published an address	Yield
Hacker News "Who is hiring?" threads (2024 → Sep 2026)	2,792	304	11%
Y Combinator open-source hiring directory	736	0	0%
remoteintech/remote-jobs public catalog	531	0	0%
GitHub repository homepage fields	330	0	0%
Agency directories (DAN, Semrush listings)	525	522	99%
Show HN launches — domain taken from the post URL	343	44	13%
dev.to posts whose canonical is a company domain	220	0	0%
npm and crates.io package homepage fields	190	0	0%
Job feeds (WeWorkRemotely, Jobicy, Arbeitnow, RemoteOK, Remotive, LaunchingNext)	182	0	0%
Reddit, Mastodon and HN signal threads	142	0	0%
Product Hunt launches	37	0	0%
Total	6,032	998	17%

Two readings matter more than the total.

The biggest family publishes almost no mailboxes. 2,792 rows came from hiring threads, and only 304 of them expose an address. A "Who is hiring?" post gives you the company and the role — it does not give you the inbox. That is not a flaw of the source, it is what the source is for.

The only family with near-total contact data is agencies. 522 of 525 rows carry an address, because an agency puts one on the page on purpose. Which also means: a list built only from job feeds is a list of companies, and a list built only from directories is a list of competitors.

Rule 1: the domain comes from the post, not from the text

On job feeds the employer's domain sits inside the body copy. When you pull it out of the text, roughly half the rows are wrong — the job board itself, an ATS (greenhouse.io, lever.co, ashbyhq.com), a link inside the ad, or the same company under two ccTLDs.

When the domain comes from a structured field or from the post's own URL — Show HN, package registries, dev.to canonicals — the reject rate falls from about 50% to somewhere between 5% and 12%.

That difference is the whole reason this file counts 41 sources instead of 4,000 scraped pages. Fewer sources, better rule.

Rule 2: a domain is not a company until it answers

Every host got a live request before it entered the file, and only pages that behave like a product were kept: pricing, sign-up, demo, integrations.

Skip that step and the file fills with university course pages, documentation sites and personal blogs. It happened on my first pass: 21 candidates reduced to 10 usable rows.

Rule 3: a published address is not a verified address

Of 6,032 rows, 998 expose an address. The rest are either SMTP-checked one by one, or left out of the send queue entirely.

In the agency pull, two addresses out of 35 were placeholder text (hello@world.com, johnsmith@yourbrand.com) and three belonged to a different domain than the page they sat on. Five rows out of 35 would have gone out as working data without a domain match.

What the list is actually for

The list is the cheap half of outbound. The expensive half is the sentence that earns a reply, and the reading of what came back.

Which is why the work is scoped as work, not as a spreadsheet:

$900 Sprint, one-off — segment and definition, the checked contact list, the first touches sent, and the measurement that says what the channel owns.
$1,900/month Engine — the loop keeps running: list refreshed, sends going out, replies worked to a booked conversation, a read-out each cycle.
$2,900 Full Build — offer, landing page, a free tool, distribution and measurement.

The first test is 100 verified contacts, so the list is judged before a month is committed to.

The full write-up, with the yield table and the source rules, is on my site: B2B lead list building.

If you have pulled a list from public sources recently, I would like to know which source gave you the best address-per-domain ratio — that number is the only one that survives contact with a real inbox.

I pulled 91 remote job posts to price an outsourced SDR

Axel Freeman — Sat, 19 Sep 2026 06:21:29 +0000

I pulled nine remote job feeds on 19 September 2026 and counted what was in them. Not to make a point about hiring — to answer a question buyers keep asking in a way neither side can win: is an outsourced SDR cheaper than hiring one?

The answer is not a price. It is a denominator.

What the job feeds actually showed

The pull was WeWorkRemotely's general feed plus its eight category feeds: 91 unique posts carried the company's own domain in the post body. 65 of those domains answered with HTTP 200. Of the 65 live ones:

19 were sales, growth or marketing roles — demand generation, inside sales, heads of marketing and sales, affiliate and lifecycle marketing;
3 of those were revenue leadership titles, i.e. a company that has already decided to staff the function and is only choosing how;
across the entire pull, exactly two posts printed money: $40,000/year (a support role) and $170/hour (a contractor).

That last line is the market's real condition. Almost nobody publishes a price, so buyers compare shapes instead: who writes the list, who owns the copy, what gets reported, what happens when it stops.

The denominator nobody quotes

A strict two-variant test at a 3% base rate with a +20% relative lift needs 13,914 contacts per arm — 27,828 in total — at 80% power and alpha 0.05. At 500 contacts a day that is 56 days. At 1,000 a day, 28 days.

So the only comparable number between two quotes is:

cost per finished reading = (fee + data + tooling + mailboxes) / verdicts per quarter

Two vendors and one verdict means the second invoice bought nothing. Adding a person does not change the number of readings either, until the volume itself changes — below roughly 2,000 contacts a day, the constraint is the funnel, not the staffing.

Six rows, of which most services sell three

Element	Outsourced service	Who must own it
List	builds, verifies, suppresses	definition of a qualified account is yours
Copy	drafts sequences and variants	approval is yours; without it the clock never starts
Sending infrastructure	mailboxes, warmup, rotation	ideally your domains, so reputation stays with you
Conversations	first reply, qualification	qualification criteria are yours
Product context	nothing	yours — nobody external can price or promise for you
Reporting unit	sends, opens, replies	yours to set: the readable unit, the owned number, the stop rule

The failure mode is a service that sells the first three rows, reports on them, and leaves the last two empty. You end up owning a dashboard of activity and no verdict.

Ten questions that separate two SDR quotes

Who is the named person on my account, and how many accounts do they hold?
What is a qualified conversation, in words I can point at? ("A reply" is not an answer.)
Which number does the channel own, and what volume does it need before that number can be read?
What is the stop rule — at what cost per qualified conversation do we stop?
Who owns the domains, mailboxes and sending reputation if we part ways?
Who owns the list, and can I export it with verification results and dates?
Are data, tooling and mailbox costs inside the fee or outside it?
What is the reporting unit — sends, replies, meetings, or finished readings with volume attached?
What does the first week produce that I keep even if we stop on day seven?
Which of my definitions did you have to invent because I never wrote them?

Question 10 is the useful one. The honest answer is a list of the things the engagement should have started with.

What the first week should hand over

Four artifacts, keepable even if the engagement ends immediately: the qualified-account definition, the number the channel owns, the volume that number needs before it can be read, and the stop rule. Everything after that is execution, and execution is cheap to replace.

I run this on my own domain, which is why the numbers above are countable rather than claimed. If you want the same page of definitions written for your funnel before you take another quote, that is the fixed-scope entry point: marketing engineering engagements, $900 Sprint / $1,900 Engine / $2,900 Full Build.

The canonical version of this piece, with the full table of the feed pull and the FAQ, is on my site: Outsourced SDR: what you are actually buying.

Foundations before amplification: the order AI marketing skips

Axel Freeman — Sat, 19 Sep 2026 05:29:29 +0000

Foundations before amplification: the order AI marketing skips

Almost every AI-marketing engagement I get asked to price starts at the wrong end. The brief is amplification: more posts, more citations, more ads, more agents. Amplification is step five. When it is step one, it multiplies a number nobody has defined yet, and the result is a busier month with the same amount of information in it.

I wrote the five steps down on my own domain, with what each one has to produce before the next one is allowed to start: the FREEMAN framework.

F — Foundations: the audit that decides everything after it

Before any channel work there is an unglamorous week: what is tracked, what is duplicated, which conversions are double-counted, which form fields never reach the CRM, what the actual baseline is. The deliverable is not a slide. It is a short document that states, in numbers, what the funnel currently does and which of its numbers are trustworthy.

This is the step that gets skipped because it produces nothing visible. It is also the step that decides whether the next four produce readings or noise.

R — Relevance: the message that survives contact with a list

Relevance means one formulation per channel, tested against a defined audience, with the reply rate as the reading — not impressions. If nobody can say which message is currently winning, there is no relevance step, there is copywriting.

I — Integration: schema, discovery, one system

This is where the machine-readable layer goes in: structured data, an llms.txt, a sitemap that matches reality, pages that answer a question in the first paragraph because that is the part an answer engine quotes. Integration is not an integration project. It is the decision that the system reads from one set of definitions.

M — Measurement: one owned number per channel, monthly

Each channel gets exactly one number it owns, stated before the month starts, plus a stop rule expressed as a cost per qualified conversation checked on a fixed date. A channel that reports four numbers owns none of them.

The arithmetic here is unfriendly and worth knowing in advance: one strict two-variant test at a 3% base rate with a +20% relative lift needs 13,914 contacts per arm — 27,828 in total at 80% power. At 500 contacts a day that is 56 days. Media money is rarely the constraint; volume is. You can check it yourself with a free test planner and a queue planner.

A — Amplification: only what already proved itself

External signals last: distribution, listings, posts, PR, archive snapshots. By the time you get here you know which message to amplify and which number is supposed to move — so amplification has a kill rule instead of a content calendar.

The order is the product

The steps are cheap to name and expensive to reorder. A team that starts at A will spend the quarter learning that its baseline was wrong; a team that starts at F and R will finish the quarter with one verified message and a channel that can be scaled or stopped on evidence. Neither quarter costs more. Only one of them ends with a decision.

I run this as a fixed-scope engagement: Sprint $900 one-off (foundations, definitions, tracking, stop rules — yours whether or not you continue), Engine $1,900/month (one channel end to end, a written record and an owned number each month), Full Build $2,900 (the whole loop including the pipeline). Prices and deliverables are published on the offer page, and the artifacts this produced on my own domain — packages, accepted third-party listings, archived snapshots — are on the proof page. The method also ships as an npm CLI and a public playbook repository if you would rather read the operating file than take my word for it.

Hire in-house or contract? Count the readings a quarter can finish

Axel Freeman — Sat, 19 Sep 2026 05:04:12 +0000

Hire in-house or contract? Count the readings a quarter can finish

The argument about hiring a marketer in-house versus bringing in an engineer for one channel is usually had in the wrong units. Salary, retainer, "commitment", "culture fit" — none of them decide anything. What decides it is how many finished readings each option can produce this quarter, because an unread month costs the same as a decisive one and teaches you nothing.

I wrote the whole comparison out on my own domain, with the arithmetic it depends on: marketing engineer vs an in-house hire.

The floor comes first, and it does not care who is on payroll

One strict two-variant test at a 3% base rate and a +20% relative lift needs 13,914 contacts per arm — 27,828 in total at 80% power and alpha 0.05. At 500 contacts a day that is 56 days. At 1,000 a day, 28 days. Replies read cheaper than money: an email test reads on 1,500–2,000 sends per variant. A strict web A/B needs roughly 10,000 visitors per variant and 300+ conversions.

So at moderate volume a quarter finishes one or two honest readings. That is the ceiling, and it is a property of the funnel rather than of the staffing model. Two people reading the same 500 contacts a day produce the same single verdict and twice the salary.

What a hire actually pays before its first reading

Ramp. The readable-unit clock starts when the first contact goes out, which is after the person has learned the funnel, placed the tracking and got copy approved. Before that there is a month of tooling and internal archaeology — and if nobody has written down the definitions, that archaeology is the job.

The fixed-scope route starts differently: definitions, tracking and stop rules are the first artifact, copy gets approved once, and the clock starts on the first contact rather than after onboarding. That is the only structural difference between the two options, and it is worth a full quarter at 500 contacts a day.

You can check the arithmetic yourself with free tools that do nothing but maths: compute your own floor, then see how many verdicts your volume can finish.

When in-house is genuinely the better answer

I would rather say this than pretend otherwise: above roughly 2,000 contacts a day, a single finished test fits inside a month, and there is enough operational surface — sequencing, data hygiene, landing pages, the queue, the approvals — to keep a full-time owner busy between readings. Context accumulating inside one head beats any external arrangement at that volume.

Below it, the constraint is the funnel. Hiring does not raise the reading rate; it just adds a fixed cost to the same queue.

The four definitions the hiring round needs anyway

Whatever you choose, four things have to exist or nothing reads:

what counts as a qualified account;
which number the channel owns;
what volume that number needs before it can be read;
what the stop rule is, stated as a cost per qualified conversation checked on a fixed date.

Hiring before those exist means paying someone to guess at them and then paying again when the first test contradicts the guess. Those four lines are also the most useful interview material you can have: "I would test a few subject lines and scale the winner" and "1,500–2,000 sends per variant before reading, one approved formulation per channel, stop rule at a stated cost per qualified conversation" are not the same candidate.

What it costs, in public numbers

Sprint $900 one-off — the definitions, the tracking and the stop rules written down, usable whether the next step is a hire or a retainer. Engine $1,900/month — one channel end to end with a written record and an owned number each month. Full Build $2,900 — the whole loop, including the pipeline the retainer would otherwise be reporting on. Media spend, tools and data are never inside those numbers.

Prices and the deliverable list are on the offer page, and the artifacts produced by running this on my own domain are on the proof page. The method ships as an npm CLI and a playbook repository if you would rather read the operating file than take my word for it.