The problem
Every outbound system I had worked inside had the same shape. Build a list, enrich all of it, then filter.
That order means paying to learn things you could have known for free. It also means messaging accounts that were never going to convert, which costs more than the credits do.
The system
Nine sequential decision gates, ordered by what each check costs, cheapest first. An account that was going to fail failed before it reached anything expensive.
Tier 1, free structural checks. Headcount band, geography, category exclusions. Anything decidable from data already in the row. No API call, no credit, no latency.
Tier 2, cheap signal reads. Hiring activity and funding events. Costs a call, not a credit. This is where an account stops being a company and becomes a situation.
Tier 3, the negative signal. Tech stack detection, used to reject rather than to qualify.
Tier 4, paid contact enrichment. The only tier allowed to spend real money, and it spent it as a waterfall: Apollo, then Hunter, then Prospeo. Cheapest provider first, stop at the first verified result, never call the second if the first one answered.
Self-hosted, running unattended on a schedule, with one human review step at the final outreach stage.
The numbers
Running the same logic inside Clay on a separate project, nine companies went through full enrichment for 66 credits total. Roughly eight credits per row that passed, five per row that was rejected.
Scale that to a hundred accounts at a 70 percent rejection rate. Thirty passing rows at eight credits is 240. Seventy rejected rows at five is 350. Total 590, against 800 if you enrich everything. A 26 percent saving.
That saving is real and it is not the point. The point is the seventy accounts you did not message. A bad send does not cost you a reply, it costs you a domain, and a domain takes weeks to warm and minutes to burn.
The decisions
Tech stack detection is a negative signal, not a positive one
If a company already ran Apollo, Outreach or Instantly, the system rejected it even on a perfect ICP match. The problem I would be selling them was already solved. There is a tool, an owner, a contract, a renewal date and an internal champion who chose it. That is a displacement cycle wearing a warm lead’s clothes, and it takes four times as long for half the odds.
Most scoring systems treat a detected tool as a positive, because it proves the company is sophisticated enough to buy software. That is true, and it is the wrong conclusion.
The gate I did not build at first
The first version was fully autonomous. Everything the model classified as good went forward automatically, and I was proud of that.
One bad send changed my mind. A human review step went in at the final outreach stage and I would not remove it. Not because the classification is unreliable, but because the two error types cost wildly different amounts. A false negative costs one account out of thousands. A false positive costs the channel.
Anything that can only be wrong in one direction can be automated. Anything whose failure mode is expensive and irreversible gets a human.
What I would build differently
This ran on a self-hosted n8n instance with the workflow definitions living in that instance’s own database. The design was version controlled in my head and in my notes. The system was not.
The reply classifier I built afterwards is the direct answer to that: a plain Python package, in git, with sixty-five offline tests and every decision rule sitting in a file you can read without booting anything. Same reasoning about cost and failure modes, stored somewhere that survives the machine it ran on.
That is the more expensive lesson of the two, and it is the one I would lead with.