A lesson from our own Claude lead sourcing build

Hey there,

David here.

The build I want to write about this week worked perfectly on the first run. That is exactly what made it hard to catch.

We had connected the provider APIs to Claude, named the order, and asked for leads. Twenty leads came back clean. Five hundred came back worse than a list we would have assembled by hand. And… nothing in the run reported a problem.

01Why it degrades quietly

Fire a large number of provider calls at once and the whole thing clogs. Quality drops from there, and the list you get back is the last thing to tell you.

The pattern people are sharing right now is real and it works. What a demo does not include is pacing, because at demo volume nobody needs it. Every request goes out at once with nothing managing the order.

Clay already solved this inside its own ecosystem. Build the same thing in Claude and that half becomes yours to build.

02What we run now

Two pieces, and only the second one is interesting.

The waterfall:

• The bench first, the leads we already sourced for that client
• Then new sourcing across Blitz, AI Ark and Prospeo
• Apify for the ones the others cannot see, like Google Maps and Zillow
• The ICP picked fresh, or reused from a campaign that is already working
• Free-text instructions on top, for the run that does not fit the default

The execution layer:

• Every provider request queued through Trigger.dev
• Each request on its own row, running in parallel with pacing
• Retries and backoff per request rather than per batch
• A spend ceiling on every provider, and a second press above 100 euro

Bench first matters more than it looks. The first question on a top-up is whether we already own the right leads for that client.

The Apify line matters too. Every normal provider reads the same LinkedIn-shaped universe. Local businesses, property and marketplaces sit outside it, so each one needs its own scraper.

Underneath, Claude hands the job to an executor skill in the back end. A skill defines the normal path, and the free-text box can redirect it. If something is unclear, it asks a question before it runs. Credentials never sit in Claude. The executor resolves each provider key from 1Password at runtime.

Where the leads land depends on the run. The Clay runs come back as a CSV we upload. The Claude runs push straight into the campaign.

03What to watch if you build this

The queue is the easy part to describe and the easy part to get wrong. Four things are worth knowing before you start.

• The instinct is to wrap the waiting calls in a Promise.all so they run together. That is not supported. Use the batch trigger instead, which takes up to a thousand items.
• A finished run is not a successful run. The wait call hands back a result object rather than the provider's data. Check that it succeeded before you read it. Skip that and an empty provider response looks exactly like an empty lead list.
• Add jitter to your retries. Without it every failed request retries on the same beat, and the original problem is back.
• Pacing is cheaper than it sounds. Waits over five seconds get checkpointed and do not count toward compute. The waiting itself does not add to your bill.

One more → Check the version of any tutorial you copy from. The older job-definition pattern is deprecated and will not run.

We can run a client list build at volume now. The last hundred leads hold the same quality as the first hundred. That is what makes a list size something we can promise rather than hope for.

If you have built your own waterfall in Claude, tell me what you use for the pacing layer. Just hit reply.

That is the part almost nobody writes about, and everyone building this runs into it.

PS. If you want this kind of thing built into your own GTM setup, you can book a call here