Work · AI Sales & Lead Generation
Foldnine finds its clients with a pipeline we built and operate: it discovers companies from public sources, reads their sites, scores the fit, and drafts a first message. A person approves every message before it is sent. This page is how it works, what it has done, and where it broke.
The pipeline
162
Every morning WF-01 reads public sources — the Y Combinator directory, Hacker News "Who is hiring?", and businesses in the region that list a website on OpenStreetMap — and keeps the ones worth reading. A company already known, or on the suppression list, never comes back.
264
WF-02 reads a handful of pages per company, respecting robots.txt. A cheap local model decides if it is worth a closer look; a larger one writes down what it found. Every fact carries the URL it came from — all 264 of them — and "unknown" is an allowed answer.
2 of 108
WF-04 scores fit, evidence and who would decide, and the database turns the score into a band. 74 were not a fit, 32 are worth watching. The bar is meant to be high: a message to the wrong company costs more than no message.
6
WF-05 drafts a first message from the evidence alone, then checks it: every claim must trace to a signal, and a draft that fails is blocked, never edited until it passes.
4 of 4
Each draft arrives on Telegram with its evidence. Nothing is sent until it is approved there. Approval is a state in the database with its own queue — not a setting someone can flip by accident.
What the database refuses
Suppression is a trigger. A message to anyone who asked not to be contacted is refused by the database, whatever a workflow or a model does.
Bands are generated columns. A model proposes a score; the database decides what it means.
A second first message is a unique-index violation. A bug produces a failed insert, not a duplicate email.
Model output is validated, never repaired. A response that does not match its schema is an error, recorded with its input.
Every model call is recorded. 518 of them so far, each with its input, output, model and time.
Where it broke
Four things that went wrong in the first week, and what changed because of them. Operating a system is mostly this.
24 Sep · Discovery
Blocked by the map
Six country-wide OpenStreetMap queries every morning, with retries, got the machine's address refused by the public Overpass service. The map changes slowly: a separate workflow now refreshes one country at a time, weekly, and discovery reads the saved copy.
23 Sep · Deploys
A restart that killed work
Restarting n8n during a deploy killed three runs in flight. The deploy script now refuses to start while anything runs, and waits for a gap before it restarts.
24 Sep · Research
Confident in percent
Four research runs returned a confidence of 100 or 3.5 where the schema says 0 to 1. The validator rejected them, as it should; the prompt now states the range in words the model reads.
24 Sep · Backups
A backup nobody restored
One command now restores the latest encrypted backup into a throwaway database and checks it against the live one. First run: every table matched, seven seconds.
What it runs on
Every step is a workflow: scheduled, logged, and failing into an error handler that reports on Telegram.
The system of record, and where the rules live. Migrations are numbered and checksummed.
Llama 3.1 8B for triage, Qwen 9B for research, scoring and drafting, through Ollama on the same machine. No company data leaves it.
A Mac mini, reachable only over a private network. An encrypted backup before every change, a restore drill, a health check.