Applicant Tracking System Problems: The 7 That Cost Real Money in High-Volume Hiring, and How to Avoid Them

Why do custom ATS builds end up rebuilding Greenhouse?

Because requirements gathering asks people what they do today, and what they do today is work around a tool built for a different kind of hiring. Every workaround gets faithfully specified. Six months later you own a system with the same stage by stage funnel, the same one candidate at a time interactions, and the same texting tool bolted on the side, except now it is your maintenance problem.

The specific trap in this sector is that the incumbent's shape is invisible until you name it. Greenhouse and Lever assume a recruiter evaluates each candidate. Bullhorn and JobDiva assume a staffing desk with submissions and placements. Neither assumption is wrong; they are simply not yours if you are hiring hourly workers in thousands. A requirements document written by people who have only used one shape will reproduce that shape.

The fix is to specify the volume path first and the exception path second, which is the reverse of how these projects usually run. Design the flow where nobody touches the candidate at all: knockout questions disposition on submission, apply by text captures the worker who will never finish a desktop form, interview slots self schedule against real availability, and bulk actions move hundreds of records at once. Then design what a coordinator does with the exceptions. If your first wireframe is a candidate detail page, the project has already drifted. In our delivery experience the builds that succeed at volume were scoped around throughput from the first workshop.

What goes wrong when you migrate candidate history and deduplicate at scale?

Two problems, and both are underestimated. The first is migration. Getting contacts out of Greenhouse or Bullhorn is easy. Getting resumes, recruiter notes, stage history and dispositions out with their dates and authors intact is a project inside the project, and it matters more than teams expect, because disposition history is what an audit asks for and stage history is what your time to fill reporting is built on. A migration that lands names and emails only has thrown away the asset.

The second is deduplication at ingest. The same hourly candidate applies to four requisitions across three branches over six months, sometimes with a different phone number, sometimes with a nickname, sometimes through a job board that rewrites the email address. Match too loosely and you merge two people, which is a serious problem when one has a failed background check. Match too tightly and your recruiters see the same person as a new applicant every time, which destroys the redeployment pool and inflates your applicant counts.

The fix is to treat identity as a first class problem rather than a database constraint. Use tiered matching with a confidence score, auto merge only on high confidence signals, and route everything ambiguous to a review queue rather than guessing. Keep the source application records after a merge so a merge can be reversed, because it will need to be. And migrate history with authorship and timestamps preserved, then reconcile counts per requisition and per disposition reason rather than in aggregate, since an aggregate count hides a whole category going missing.

Why do job board, background check and VMS integrations break after launch?

A hiring stack has more moving external parts than almost anything else in operations: job distribution to Indeed and ZipRecruiter, background checks through Checkr or Sterling, assessments, texting, electronic signature, onboarding, payroll and, on the staffing side, a vendor management system such as Fieldglass or Beeline. Every one of them is somebody else's release schedule.

The failures are specific. Job board feeds reject postings for reasons that are only visible in a portal nobody logs into, so a requisition sits unposted while the branch waits for applicants. Background check webhooks are delivered once, and a deployment during the delivery window loses the result silently, leaving candidates stuck in a status forever. Rate limits on an incumbent API mean a nightly sync that worked at forty requisitions starts skipping records at four hundred. Vendor management systems are the least forgiving of all: requisition data arrives in their format, on their schedule, with their identifiers, and a mismatch means a submission never reaches the client.

The fix is defensive by default. Persist every inbound webhook before processing it and reconcile daily against the provider's own record, so a missed delivery is caught rather than becoming a stuck candidate. Alert on absence: a job board feed that returned zero postings should raise a flag, not pass silently. Build retry and backoff into every outbound call. And give each integration a named internal owner, because the ones that quietly fail are always the ones nobody was responsible for watching.

What happens when OFCCP, FCRA and credential rules are not covered?

This is where high volume hiring turns a software gap into a legal one. Federal contractors owe an auditable applicant flow log with a disposition reason on every candidate. Background checks trigger pre adverse and adverse action steps under the Fair Credit Reporting Act with waiting periods that must actually be observed. Healthcare and transportation roles add credential rules: a nursing licence, a life support certification, a medical examiner's certificate, each with an expiry date that cannot lapse while someone is on assignment.

When the system does not cover this, the gap is filled with spreadsheets and calendar reminders. That fails in two directions. An audit asks for a flow log and receives an export nobody can reconcile. Or a certification expires mid assignment, a worker stays on a client site without it, and you find out when the client does.

The fix is to model compliance as data with enforcement, not as reports produced later. Every disposition writes to a flow log with a reason code at the moment it happens, including automated knockouts, which are the ones most often missing. The adverse action sequence is a state machine that will not permit the final step before its waiting period has elapsed, rather than a task somebody is asked to remember. Credentials are dated records that alert the recruiter and the worker ahead of expiry and block assignment once lapsed. None of this is difficult engineering. It is simply work that gets deferred because it does not fill a requisition this week.

Should you build custom or configure what you already own?

Stay bought when your hiring is genuinely considered rather than high volume: standard corporate roles, a recruiting team under roughly fifty, no unusual compliance, and no staffing economics. Greenhouse, Lever and Ashby are good products, and running your own software is a commitment rather than a saving. For many companies the seat fee is cheaper than the responsibility, and we say so on calls regularly.

Before building, check whether a purpose built volume tool solves it. Fountain and Paradox exist precisely for high volume hourly hiring and will beat a custom first release on time to value. If your problem is only that the front of the funnel is too slow, buying the front of the funnel is the cheaper experiment.

Build when the signals stack. Your seat renewal has crossed six figures and climbs every time you add a recruiter. You are processing thousands of hourly applicants a month and paying for three add ons to do what one system should. Your bill rates, pay rates and margins live in spreadsheets because the applicant tracking system has no concept of a submission, a placement or an assignment. You export before every Monday numbers review. And the workflow rule you need is one the vendor will not ship. When those describe your ordinary Tuesday, building becomes the cheaper path rather than the ambitious one.

How do hidden costs get into the quote?

Integration count is the biggest driver and the most frequently understated. Each connection is real engineering with its own authentication, error handling and reconciliation, and they are not equivalent: a job board feed is a fraction of the work of a vendor management system integration. Count them precisely and price them individually rather than accepting a line that says integrations.

Data migration is second. Resumes, notes, stage history and dispositions with dates and authors intact is a different exercise from a contact export, and it usually needs its own investigation phase to find out what the incumbent will actually give you.

Compliance depth is third. Applicant flow logging and an enforced adverse action sequence are exacting rather than large, and the cost is in getting the detail right with your counsel rather than in screens.

Fourth is peak volume engineering. Ingesting thousands of applications an hour without duplicating records or losing webhook deliveries is a real problem with a real price, and it is invisible in a demo built against a hundred candidates. Ask explicitly what happens when ten thousand applications arrive in an hour, and make the answer part of the contract rather than part of the sales conversation.

What separates a build that works from one that fails here?

The working build models your actual entities. For an employer that means requisition, application, candidate identity and disposition with a reason. For a staffing firm it means candidate, submission, placement and assignment as first class objects, with margin computed as bill rate minus pay rate on every deal, a redeployment pool that surfaces contractors the day they roll off, and credential expiry that blocks assignment. If a developer whiteboards generic records and relationships without asking what a submission is, they will rebuild your incumbent's limits with your logo on it.

The second difference is that reporting comes from one data model rather than four exports. Fill rate by branch, submissions per recruiter and margin by client should update as the day happens. The moment your operations lead has to wait until Wednesday for Monday's number, the system has failed at the thing it was bought for.

The third is that the volume path is the default and the human path is the exception. A coordinator should manage what the rules could not decide, not process what the rules should have handled.

The fourth is ownership. Confirm in writing before work starts that you own the code, the intellectual property and the infrastructure accounts, with the right to take it to any developer. At Digital Heroes the client owns the code from the first commit. Escaping per seat licensing is one of the main reasons to build, and it is worth very little if you have simply exchanged one lock in for another.