The full story of the system that found tradespeople worth selling a website to: how it searched, how it filtered, what it cost, where AI actually helped, and whether the machine could be pointed at something new.
This system is currently retired. On 22 June 2026 the "send" side was deliberately switched off with a guard in the code, because the Telegram bot kept re-announcing old prospect batches every time someone ran the tool by hand. There was never an automatic scheduler. The website-building and research side was left untouched and still works.
Everything below describes the machine as it was actually built and run, read straight from the code.
The machine's job was to find busy tradespeople with no proper website. It picked a town and a trade (say, plumbers in Brighton), pulled a list of every such business from two different sources, then put each one through five quick checks: has a phone number, has at least 10 Google reviews, has at least 5 photos, had a review in the last four months, and, crucially, has no real website. A business that failed any check was dropped for free.
Survivors got the expensive treatment: their Facebook, Instagram and Checkatrade pages were hunted down by name, their photos counted, and possible logos collected. One AI step double-checked that each found page really belonged to that business and not a namesake. The finished prospect then appeared as a card in Telegram with two buttons: Approve or Swap. Twenty approvals filled a batch, and the research phase took over.
Total tool cost per qualified prospect: pennies. The AI ran on the Max subscription, so it added nothing.
Here is the whole pipeline in one picture, then each stage in plain words.
flowchart TD
A["Pick a town and a trade"] --> B["Build one merged list of businesses<br/>(Google + a backup robot)"]
B --> C{"Five quick checks"}
C -->|"fails any"| X["Dropped. Costs nothing more"]
C -->|"passes all"| D["Deep dig: socials, photos, logo"]
D --> E["AI double-checks identity"]
E --> F["Card in Telegram: Approve or Swap"]
A planner walked through combinations like "plumber in Brighton", "electrician in Hove", spreading its effort across towns and trades rather than draining one town dry. When it ran out of combinations it expanded on its own: it added the five nearest towns it had not tried yet, and the full list of fifteen trades (plumber, electrician, roofer, and so on).
Two safety rails kept a run from going on forever: a cap of roughly 300 combinations, and a hard 90-minute time limit. Both were logged loudly when hit, so a cut-short run never looked like a finished one.
For each combination the machine asked two different services for the same thing, then merged the answers.
First, Google Places: Google's official business directory, asked politely through its paid doorway. It answered with up to 20 businesses, each with name, phone, address, rating and website.
Second, an Apify robot that reads Google Maps the way a person does. This mattered because Google's official directory quietly misses some real businesses, and the ones it misses are disproportionately the small, no-website traders: exactly the customer Website Done wanted. The robot also brought back photo counts and review dates the official doorway leaves out.
The two lists were merged, and duplicates were spotted by phone number or by Google's own ID for the place, so the same business seen twice never counted twice.
Every business on the merged list faced five yes-or-no questions, cheapest first, and one "no" ended it there:
The order was deliberate. The first four checks used information already in hand, so they cost nothing. Around 70% of businesses fell at these free fences, which meant the paid digging in the next stage was never wasted on them. The code even says so: "we never burn Apify on the ~70% that fail the cheap gates."
Survivors were worth spending on. The machine now went looking for everything else the business had online, searching by name, because a trader with no website has no links to follow:
The bar a prospect had to clear was simple and human: a logo plus at least five real photos. That is what makes a website buildable on day one.
One question is genuinely hard for ordinary code: is this Facebook page really this "Eastbourne Roofing", or a different business that happens to share a word? Attaching the wrong page would be worse than attaching none, so a single AI step read each found profile and gave a keep-or-reject verdict, under a strict instruction: when in any doubt, reject.
Even here the code stayed in charge where it could. If a page showed the same phone number as the Google listing, it was kept automatically, no AI needed, because a phone match cannot be a namesake.
Each finished prospect became a short card: name, trade, town, review counts, follower counts, photo count, and a link to a one-page review document. Cards arrived one at a time. Approve pulled the next card; Swap discarded and pulled the next. If more than one possible logo had been found, the bot asked which one was right. At 20 approvals the batch was full and the research phase started on its own.
sequenceDiagram
participant M as The machine
participant T as Telegram
participant A as Alex
M->>T: One prospect card
T->>A: Approve or Swap?
A-->>M: Approve (and pick the logo)
M->>T: Next card
Note over M: 20 approvals fill a batch, research starts
The heavy collecting was already done by this point, frozen into a dossier per prospect. The research phase that followed was light: it cleaned up the chosen logo (crop it, make the background transparent, trim it, with a hard rule that a client logo is always transparent, never sat on a box), pulled brand colours from it, and ran one AI pass to draft the services list, tagline and voice from the collected evidence. From there the website build pipeline took over, which is its own story.
Six outside tools did the work. Three were flat or free, three were pay-as-you-go, and the code wrapped every pay-as-you-go call in a hard spending cap.
flowchart TB
subgraph FLAT["Flat fee or free"]
CL["Claude AI, on the Max plan"]
GA["Google keyword numbers"]
SA["SerpApi search data"]
end
subgraph PAY["Pay per use, capped in code"]
GP["Google Places directory"]
AP["Apify robots"]
FC["Firecrawl page reader"]
end
FLAT --> P["The pipeline"]
PAY --> P
| Tool | What it did | What it cost |
|---|---|---|
| Apify | The robot fleet: read Google Maps, Facebook, Instagram, Checkatrade, and ran real Google searches. | About $34.80 a month flat. On top, each robot run had a hard cap written into the code (50 to 90 cents per prospect at most), and the logged reality was fractions of a penny per run. |
| Firecrawl | Read a web page and handed back clean text. Used to read existing websites and blogs. | $19 a month. |
| SerpApi | Google search results as data, used for rankings and the growth report, not for finding prospects. | Free for 250 searches a month, then $25 a month. The code kept it switched off by default to stay inside the free allowance. |
| Google Places | Google's official business directory. | Pay per question, roughly 2 to 3 pence per search. A full sweep of ~300 town-and-trade combinations came to a few pounds. |
| Google Ads numbers | How many people search for each phrase every month. Powered the growth report. | Free. The daily allowance (15,000 questions) was never close to being used up. |
| Claude (the AI) | Every AI step in the pipeline. | £0 extra. Everything ran on the Max subscription. A guard in the code refused to start if the pay-per-use key was present, so a bug could never quietly run up a bill. |
Two honest numbers, because "cost per prospect" depends on what you count:
The honest headline: the AI never decided anything a calculator could decide. Every number, every filter, every yes-or-no gate was ordinary code. The AI was used only where judgement or language was genuinely needed, and even then its answers were checked.
The strategy document behind each growth report captures the rule in one line: the numbers are computed by code, and "the LLM still writes prose only." The reason was trust: a client-facing report can survive dull writing, but not a made-up number.
Early on, an AI step was allowed to guess a business's Checkatrade address. For one prospect (PestAway) it invented a page that did not exist. That produced a lasting rule you can still read in the code: nothing an AI claims is used until ordinary code has verified it. Checkatrade pages are re-checked by comparing the name printed on the page itself, so a wrong address "must never dress the site in a stranger's photos". The AI proposes; the code confirms.
One more honest wrinkle: the design document for this pipeline promised "zero AI in discovery". The code as shipped kept one AI step anyway, the identity check, because name-matching namesakes is the one job ordinary code could not do reliably. The promise and the code disagree, and the code was right to.
The question asked of this document: could the same machine work as a general lead generator or competitor analyser for other sectors? Here is the honest split of what travels and what is bolted to UK trades. This is an assessment, not a recommendation; nothing here is a decision.
Worth naming: the machine already collects, per business, its reviews, ratings, photos, social reach, activity level and web presence. Pointed at businesses that do have websites, that same dossier is a competitor profile. And the growth-report side already owns the other half: search volumes per phrase (free from Google Ads) and live rankings (SerpApi). The pieces of a "who is winning in this town and why" report exist; what does not exist is the report itself.
The map is drawn. The call is yours.
Written 22 July 2026 by reading the orchestrator code and design documents in the websitedone repository (discovery pipeline, research sources, cost guards, and the plans under docs/superpowers). Untracked file: not part of the deployed system.
Flat-fee figures (Apify ~$34.80, Firecrawl $19, SerpApi $25 past the free 250) are the subscription prices at the time of writing; per-call caps and behaviour are quoted from the code itself.