You're renting a for-loop

The enrichment pipeline I run processes over 10,000 leads a month. It started life in Clay, and most of it no longer lives there. That migration is the most useful thing I can tell you about GTM tooling, so here is the reasoning rather than the conclusion.

The step I refused to buy

At one point the obvious move was Claygent — point an agent at each row, let it go find the thing, pay per row. It reads like magic in a demo.

Look at what the step actually does, though. Open a Google Business Profile. Read the phone number. Read the review count. Write both into a column. The field is at a known address in a known structure. There is no ambiguity to resolve and no judgment to exercise. It is a for loop with a network call in the middle.

Paying agent pricing per row for that is the most expensive way to run a for-loop. You are not buying intelligence, because none is required. You are buying a very sophisticated system to do something a thirty-line script does deterministically, and paying a premium per execution for the privilege.

Agents earn their cost on judgment. "Read this messy about-page and tell me whether they sell to enterprises" is worth an agent. "Fetch the field at this known location" is not, and the difference is worth real money once you multiply by ten thousand.

What I kept renting, and why that isn't a contradiction

The pipeline was prototyped in Clay. That was correct. Clay stayed useful for the parts still changing shape every week.

This is the part people get wrong in both directions. The build-everything crowd treats any SaaS line item as a failure of nerve. The buy-everything crowd treats any custom code as a maintenance burden waiting to happen. Both are picking a side of a question that has to be answered per step, not per company.

I use three tests.

Core or commodity. Is this step a thing I win on, or is it plumbing? The choice of Google Business Profiles as the primary source instead of a B2B database is core — it is the insight the whole pipeline rests on, because Apollo-style databases are weakest exactly where SMB and local data lives. Making an HTTP request is plumbing. Own the first. Rent the second, or write the thirty lines, but do not agonise over it.

Unit economics at target volume, not at prototype volume. This is the one that catches people. A price that is invisible at 100 rows a month decides your budget at 10,000. When you are testing, per-row pricing feels free, because 100 rows of anything is free. The moment the thing works, volume goes up by two orders of magnitude and the pricing model you chose while it was a toy is now the largest line item in the function. Evaluate the price at the volume you are trying to reach, not the volume you are at.

Rate of change. Anything still being redesigned weekly belongs in a tool that makes redesign cheap. Custom code has a fixed cost you pay in engineering time every time the design changes. While the shape is unstable, that cost is paid over and over. Once a step stops changing, that cost goes to zero and the per-row saving compounds. Stability is what makes a step ready to graduate, not volume alone.

So the stable, high-volume steps moved to custom code — n8n and Python. The unstable ones stayed where iteration is cheap. Nothing about that is ideological.

The shape this produces

Once you apply those tests per step rather than per platform, the architecture falls out on its own.

Scrape Google Business Profiles first, because the marginal cost of a record is near zero. That single property is what makes everything downstream affordable — you can afford to look at every lead because looking is free.

Use review count and profile activity to confirm a real business, and read an underinvested digital presence as the ICP signal it is. Intent qualification arrives free, as a by-product of a scrape you already paid for.

Fire the paid database only on the records where the free source missed a usable email or decision-maker. Credits burn on misses, never on the full list. This is the whole economic argument for a waterfall: the expensive source is the exception path, not the default path. Run it the other way round — paid database first, scrape as backup — and you pay several times more for data that is worse on this segment.

Verify every email before anything sends. Not as a data-quality nicety: one bad batch can burn a sending domain's deliverability for weeks, and the damage lands on every campaign running from that domain, not just the batch that caused it. The gate is the last cheap place to catch it. After the send there is no cheap place.

Then route into the CRM, split to calling and cold email. That last step is where the number came from — roughly an 85% cut in lead response time — and it came from deleting a manual research step, not from making anyone work faster.

The actual test

Most build-versus-buy arguments are really arguments about identity. Engineers want to build. Operators want to ship. Both dress the preference up as strategy.

The honest version is narrower and more boring. For this step, at the volume I am actually trying to reach, with the rate of change it actually has — which is cheaper, and what does the difference buy me?

Sometimes the answer is that the platform wins and you should keep paying, happily, because your volume does not justify owning it yet. That is a real answer, not a failure. I built a calculator that will tell you so in as many words, and it tells plenty of people to keep renting.

But past a certain volume of stable, deterministic workflow, you are not buying flexibility any more. You already know what the workflow is. You are renting a for-loop, at per-execution prices, forever.