Why custom beats Zapier for recruitment workflows

Every six months or so, an agency owner asks me whether they could build what we build using Zapier or Make.com. The honest answer is: for the first 20% of the workflow, yes. For the rest, not really.

This isn't a marketing answer — Zapier is a great tool. Most agencies should use it for ten things. But sourcing automation isn't one of those ten, and it's worth explaining why.

Zapier is built for connecting two systems and passing structured data between them. When a candidate replies to an email, log it in Bullhorn. When a new role is added to your ATS, post it to LinkedIn. When a calendar invite is accepted, send a confirmation from Postmark. These are linear flows with clear inputs, clear outputs, and a small handful of failure modes.

If your sourcing workflow is "watch a single source, do one thing per candidate, log it somewhere", Zapier will absolutely run that. Build it in an afternoon, ship it, move on.

Sourcing automation gets complex fast, and the complexity isn't in any one step — it's in how the steps interact.

You're not pulling from one source, you're pulling from eight, each with different rate limits, different auth flows, different data shapes, and different failure modes. You're not running a fixed rule against each CV, you're sending it to an LLM with a structured-output schema, retrying on malformed JSON, caching the result so you don't pay for it twice. You're not just scoring candidates, you're vector-embedding them, doing top-K retrieval against the role embedding, then re-ranking the top 50 with a second LLM call.

You're also dealing with what happens when something goes wrong. A LinkedIn scraper getting rate-limited shouldn't fail the whole job — the system should retry, log it, and continue with the other seven sources. A CV that doesn't parse cleanly shouldn't get silently dropped — it should flag for human review. A scoring result that contradicts a hard requirement should be filtered out before it ever reaches the recruiter.

Zapier can express the happy path for any of these individually. What it can't really do is the error-handling, retries, caching, queuing, and observability that production sourcing needs. You end up with twelve Zaps that work in isolation, fail unpredictably together, and silently lose candidates when something goes wrong upstream.

The standard argument for Zapier is "it's cheap". For low-volume linear flows, yes. For sourcing across an agency running 30+ active roles, the per-task pricing model gets expensive fast — and the engineering time to make a Zapier-based system reliable starts looking similar to just building it properly.

A custom build on a Python backend with proper queues, a real database, proper LLM caching, and observability costs more upfront. It costs less to run, less to debug, and substantially less when you need to add a new source, change scoring weights, or onboard a new client.

If you're an agency owner trying to decide, here's the test we use:

Single source, single workflow, low volume → Zapier. Multiple sources, structured AI processing, anything where a silent failure costs you a placement → custom.

The fact that this question keeps coming up tells me people genuinely want to know — not because they want the cheapest option, but because they want to spend the right amount on the right tool. Sourcing isn't where you save money. It's where you make it.