Why Recruitment Agencies Cannot Run on an In-House ATS

I made this mistake myself.

When I started ScalingPPL, I used tools that were built for the companies I was recruiting for — because those were the tools I knew. It worked until it did not. The moment I had three clients running simultaneously, the architecture started fighting me. Candidate confidentiality between clients was a manual process. Client shortlist delivery was a PDF email. Revenue tracking was a spreadsheet I updated when I remembered to.

None of that was a process failure. It was a tooling failure. I was using tools designed for one employer, one pipeline, one set of hiring managers. I was running five clients.

Here is the architectural reason this always breaks.

The single-entity problem

Every major in-house ATS — Greenhouse, Ashby, Lever, Workable — is built on a single-entity model. One company. One set of hiring managers. One candidate pool that belongs to that company. The data model reflects this: there is no "client" entity because there does not need to be one. In-house teams do not have clients.

Recruitment agencies are multi-entity operations. Client A and Client B are two separate businesses with two separate confidentiality requirements. A candidate active in Client A's CFO search must be invisible to Client B's hiring manager — not through a permission workaround, but structurally, at the data level.

When you take a single-entity ATS and try to run multi-client operations on it, you immediately need workarounds for the things the data model does not support. And workarounds compound. The first workaround is a tag. The second is a separate account. The third is a spreadsheet. By month six, you have an ATS you use for the bits it handles and a spreadsheet system for the bits it does not.

The four things that break specifically

Candidate confidentiality. Without client-level data isolation built into the architecture, you are one misconfiguration away from a client seeing candidates they should not see. In practice, most agencies manage this through discipline and careful access controls. In practice, discipline fails under pressure. One accidental disclosure is enough to damage a client relationship that took two years to build.

Client shortlist delivery. In a properly designed agency ATS, a client logs into their portal and sees their pipeline, their candidates, their feedback forms. In an in-house ATS repurposed for agency use, you create a PDF, write an email, wait for a reply, update the system manually with their feedback. This workflow does not scale beyond three clients before it becomes a genuine operational problem.

Revenue and placement tracking. In-house tools track hires. They do not track placement fees, retainer installments, margin per role, or billed-versus-collected per client. If your ATS cannot tell you your revenue pipeline, you are running your business finances in Excel alongside your recruiting operations. That means two sources of truth and at least one of them is always wrong.

Cross-client candidate matching. When a new brief comes in from Client B, your best lead might be a candidate currently in Client A's process who is not the right fit there but is ideal here. A properly designed agency ATS surfaces this at the recruiter level while keeping it invisible to both clients. In an in-house ATS, this match either gets missed or requires manual cross-referencing across separate views.

The migration cost is lower than you think

The most common reason agencies stay on the wrong tool is the data migration argument. Years of candidate history, notes, application records.

Modern agency ATS platforms import from Greenhouse, Ashby, and Lever via API. The actual migration takes 24-48 hours. The data does not disappear — it moves. The real cost is one week of parallel operation while the team transitions. That is a one-time cost against the ongoing cost of building workarounds into every search you run.