Key takeaways
- Our whole prospecting research stack runs under a hard monthly spending cap, on purpose, and the cap made the system better rather than smaller.
- One line item ate seventy percent of a blown budget on a previous account, and it was not the data. It was the proxy.
- Residential proxy runs about eight dollars a gigabyte. Datacenter proxy is a fraction of that, and only two of our targets genuinely need the expensive one.
- When the cap is hit, jobs fail with an error that looks exactly like a broken login. Knowing that saves an afternoon.
- The real finding: leads were never the bottleneck. The free parts of the stack turned out to be worth more than the paid parts.
Every scraping job in this business goes through one script. It checks the account's spending against the cap before it does anything, it makes you choose a proxy type instead of accepting a default, and when the run finishes it prints what that run actually cost. None of that is fancy. All of it exists because of a bill.
The bill
An older account of ours hit a one hundred dollar monthly ceiling and died there. When I pulled the itemized usage, the shape of it was not what I expected:
- Residential proxy transfer: about seventy dollars
- Compute: about eighteen dollars
- Per event actor charges: about eleven dollars
- Everything else combined: about a dollar
Seventy percent of the spend was not data. It was the pipe the data came through. And it burned in about nine days, roughly a gigabyte a day, then the account capped and stayed dead for the rest of the cycle.
Here is what made it avoidable. Residential proxy is genuinely required for exactly two targets we care about, Instagram and TikTok, because those platforms block anything else. Google Maps, search results, YouTube, Zillow, and the Facebook Ad Library do not need it at all. Every one of those runs perfectly well on datacenter proxy at a fraction of the price.
Nobody chose to spend seventy dollars on proxy. What happened is that the tools default to the expensive option and nobody overrode it. That is the whole story. Now the runner refuses to start without an explicit proxy choice, which is a one word change that permanently removed the most expensive mistake available to us.
The error that is not the error
Once an account passes its cap, jobs come back with a permissions style failure that reads like a dead token. It is not. The credentials are fine, the account is fine, the ceiling is just closed until the cycle resets.
Worse, reads keep working. You can still list your data, check run history, and query usage while every actual job is blocked. So a quick manual test succeeds, you conclude the connection is healthy, and you go debug the wrong thing. The runner now checks the cap first and says so in plain English, which is a small feature that has paid for itself several times.
What the money actually buys
Priced per result, this data is much cheaper than people assume. A Google Maps business listing runs well under a cent. A review is a small fraction of a cent, and there is a cheaper actor that goes ten times lower again for big pulls. An ad from the Ad Library, a page of search results, a YouTube video's stats, all fractions of a cent.
Which means two hundred local businesses with their full listing details cost roughly the price of a coffee. Sit with that number for a second, because it changes what the exercise even is. Research was never the expensive part of prospecting.
There is one genuine landmine in the pricing and it is worth naming: a transcript add on that bills per started minute of video. In bulk it dwarfs everything else on this list combined. We never enable it in bulk, and the rule is written into the catalog rather than left to memory.
The rule that keeps the catalog honest
Every tool we use is written down in one file with its exact identifier, its price, and which proxy it needs. Never invent one. If a job needs something not in the catalog, search first, verify it exists, then add it with its real price.
This sounds like bureaucracy for a one person operation. It is not. A guessed tool name fails in a way that looks like a network problem, and a guessed price is how you find out about a bill after it arrives.
The finding I did not expect
We built out a whole stack of research skills, priced every one of them, and then discovered that running all of them at their natural cadence would cost roughly double the cap. So we had to rank them, which forced an honest look at what each one was actually for.
At that point I counted the pipeline. There were one hundred and sixty one open opportunities in the CRM, and seventy nine of them were sitting untouched in the first stage. Nobody had called them.
Lead supply was not the constraint. It had not been for months. What was missing was a reason to call any particular one of those seventy nine, and the two skills that fix that, auditing a prospect's website into a specific pitch and writing a genuinely personalized first line, are the two cheapest things in the stack. One of them is free even at a thousand sites.
So the budget ceiling did not make the system worse. It made me stop buying more names and start making the names I already had callable.
If you are running paid tools in your own business
The generalizable version, for any local business paying for software that bills by usage:
- Set a hard cap, lower than you think you need. Discovering the limit through a bill is the expensive way.
- Pull the itemized usage at least once and read it. The line that dominates is almost never the one you were watching.
- Find the default that is quietly premium. There is usually exactly one and it is usually most of the bill.
- Before buying more inputs, count what you already have and have not used. That count is usually embarrassing and usually the answer.
That last one is what I actually took away from all of this. Most businesses I work with on Go High Level in the Bay Area do not need more leads. They need the leads they already paid for to be workable, and that gets fixed by building better systems rather than by spending more. If that sounds like your CRM, come talk to us at optechsol.llc.