Custom Recruitment CRM Development: What You're Building

Almost every article about custom recruitment CRM development makes the same mistake in its first paragraph: it treats "recruitment CRM" and "applicant tracking system" as the same product with two names. They aren't, and the difference is not cosmetic. It changes the data model, the permissions design, the reporting layer and roughly half the scope of the build.

An employer-side ATS serves one company hiring for itself: one hiring organisation, requisitions owned by internal departments, and a candidate moving through a single pipeline toward one offer.

An agency-side CRM serves a firm that sells people to other companies. There are many client organisations, each with their own contacts, contract terms, rate cards, submission formats and approval chains. Money has two sides — what the client pays and what the contractor earns — and the business lives in the gap between them.

Commission a build without that distinction settled and you get an ATS with a client field bolted onto it, then spend a year discovering what it can't do.

TL;DR

• A recruitment CRM is a multi-client system; an ATS is a single-company one. Get this wrong and the data model gets rebuilt, not extended.
• Three things define agency software and appear in no employer ATS: client contacts as first-class records, bill/pay spread and margin, and redeployment between placements.
• Most agencies should not build a full CRM. Recruiterflow, Bullhorn, JobAdder and Crelate solve the standard case, and the standard case covers most desks.
• The build that usually makes sense is unbundled — the layer your ATS won't do, integrated against it rather than replacing it.

Agency CRM vs ATS: the differences that drive scope

The clearest evidence that this is a real architectural split rather than a marketing one sits in the incumbents' data models. Bullhorn's REST entity reference exposes ClientCorporation, ClientContact, JobOrder, JobSubmission and Placement as first-class entities alongside Candidate. An employer ATS has no equivalent of the first three, because it has no clients. That is the whole difference, expressed as tables.

What an agency recruitment CRM actually contains

Feature lists on offshore development sites tend to read "candidate management, job posting, AI matching, analytics dashboard" — true of almost any HR product and useless for scoping. Here is what actually has to be built.

1. The dual-object contact model

The foundational decision. A recruitment CRM tracks two populations with different lifecycles: candidates, and client-side contacts (hiring managers, procurement, accounts payable). Some individuals are both — today's contractor is next year's hiring manager, and the system should know that without duplicating them. Getting this right means a person record with role-based associations to companies, not two disconnected tables. Getting it wrong is the most common cause of a rebuild.

2. Job orders and the pipeline

Not requisitions. A job order belongs to a client, carries that client's contract terms, and has commercial attributes an internal req never has: agreed bill rate or rate ceiling, exclusivity, allowed submission count, contract type, and margin expectations. The pipeline also runs longer than an ATS pipeline, continuing past acceptance into onboarding, compliance clearance and start confirmation — each of which can fail after the placement is nominally won.

3. Submission tracking

The step with no employer-ATS equivalent, and the one agencies most often need customised. Submitting a candidate means producing a CV formatted to that client's specification (logo added or removed, contact details stripped, sections reordered), recording ownership of that candidate for that client for a defined period, and often pushing the submission into the client's own VMS rather than emailing it.

Ownership rules are where custom logic clusters: who gets credit when two recruiters submit the same candidate to one client, and how long the claim survives. Every agency answers differently; products answer generically.

4. Bill rate, pay rate and margin

The commercial engine. For every placement the system holds what the client is billed, what the contractor is paid, and everything between: employer taxes and statutory costs, insurance, visa or sponsorship costs, overhead, and per-client discount tiers.

Margin has to calculate at several levels — per placement, per client, per recruiter, per month — and survive mid-contract change. Rate rises, extensions and back-dated corrections must reprice without corrupting historical reporting. This is where naive builds break first, usually because rates were stored as a single number on the placement rather than a dated series.

5. Timesheet to invoice

For contract desks this is the difference between software and a spreadsheet. The chain runs: contractor submits hours → client contact approves → approved hours price against the bill rate → an invoice generates on the client's billing cycle → payment reconciles → the contractor is paid.

The complexity lives in the exceptions: overtime multipliers, holiday and sick handling, split invoicing across cost centres, purchase-order references, self-billing arrangements where the client raises the invoice, and multi-currency.

6. Redeployment and bench tracking

An employer ATS closes the record at hire. An agency's most profitable candidate is the one already placed, because placing them again costs almost no sourcing. That requires contract end dates, alerting ahead of expiry, notice-period tracking, and the bench surfaced against open orders automatically. Redeployment is the feature most consistently underweighted in build specs, and one of the strongest arguments for the incumbents.

7. Compliance documents

Right-to-work evidence, visa status and expiry, certifications, background checks, signed contracts, insurance certificates, and in regulated sectors credentialing that must be re-verified on a schedule. The system needs expiry-driven alerting, an audit trail of who verified what and when, and retention rules that satisfy GDPR or its local equivalent. Where a build genuinely wins on features, it is usually here — niche credentialing that generic products cover shallowly.

8. Reporting

Agency reporting answers commercial questions, not HR ones: gross margin by client, submission-to-placement ratios by recruiter, fill rates by job order, contractor headcount on assignment, and forecast revenue from contracts running into next quarter. Building it well means a modelled layer with dated facts, not live queries against operational tables.

Be honest about build versus buy

We build software and we run a staffing desk, so we have an interest on both sides of this — which is exactly why it is worth saying plainly: most agencies should buy.

Recruiterflow, Bullhorn, JobAdder and Crelate exist because the standard agency workflow is genuinely standard, and a subscription buys a decade of refinement in the unglamorous areas — parsing accuracy, email sync, duplicate handling, mobile, uptime — that a new build starts from zero on. The number that decides it is rarely the build price. It is the run-rate: hosting, security patching, parsing maintenance, integration upkeep, and the fact that software with no maintainer becomes a liability the day the original developer moves on.

Building deserves serious consideration in a narrow set of cases: per-client rate and margin logic no product will model, credentialing specific to your vertical, a white-label portal your clients use under your brand, or a workflow that is genuinely your commercial differentiator rather than plumbing.

The full decision framework — including the maintenance arithmetic and what you give up by leaving an incumbent — is in build vs buy: ATS for a staffing agency.

The version most agencies should actually consider

The framing that costs the least and works the most often is not "replace the CRM". It is: keep the system you already own and build only the layer it won't do.

That looks like a client-facing submission portal reading from your ATS via its API; a margin and timesheet-to-invoice layer that pulls placements out and pushes invoices into your accounting system; a VMS integration that stops recruiters rekeying submissions; or a reporting warehouse answering the commercial questions your ATS reports don't.

These projects integrate rather than migrate, so the system of record never moves and the data-migration risk disappears. They also fail gracefully — retire the layer and the business still runs.

What drives scope and effort

Scope here is not set by feature count. Four things move it more than anything else:

1. Integration count and quality. Each external system — ATS, VMS, job boards, accounting, e-signature, background checks, payroll — is discrete work, and the effort depends more on the counterparty's API quality than on your side.
2. Rate and margin complexity. Flat bill and pay rates are straightforward. Per-client tiers, overtime rules, multi-currency, statutory on-costs and back-dated corrections are where the real engineering sits.
3. Compliance surface. GDPR retention, audit trails, role-based access and any certification your clients demand in procurement expand the build well beyond the visible features.
4. Migration. Moving years of candidates, notes, documents and placement history out of an existing system is often larger than a module of the new one.

Anyone quoting a figure before those four are settled is quoting a shape, not a price.

FAQ

What is the difference between a recruitment CRM and an ATS? An ATS serves one company hiring for itself: internal requisitions, one pipeline, ends at hire. A recruitment CRM serves an agency selling people to many clients, so it tracks client companies and contacts, bill and pay rates, submissions, timesheets and redeployment. The agency system is a superset, and the extra parts are commercial rather than HR.

Should we build a recruitment CRM or buy one? Buy, unless you have a specific requirement no product models — per-client rate logic, vertical compliance credentialing, or a client-facing portal under your brand. The decisive cost is ongoing maintenance, not the initial build.

Can a custom CRM integrate with Bullhorn or JobAdder? Yes, and for most agencies that is the better project. Both expose REST APIs, which means the ATS stays the system of record while custom work handles submissions, margin reporting or invoicing on top of it.

How long does custom recruitment CRM development take? It depends almost entirely on integration count and rate complexity rather than screen count. An unbundled single-workflow layer against an existing ATS is a fundamentally different timeline from a full multi-client platform with migration — which is why scoping starts with the four drivers above rather than a feature list.

Scoping a recruitment CRM, or an integration onto the ATS you already run? First Bridge Consulting builds software and runs a staffing desk, so we will tell you when the honest answer is a subscription rather than a build. See custom recruitment software, or email success@firstbridgeconsulting.com with your stack and the workflow that isn't working. Start a conversation →

Related reading: Build vs Buy: ATS for a Staffing Agency · Custom software development services · IT recruitment services

Sources

• Bullhorn REST API entity reference — the ClientCorporation / ClientContact / JobOrder / JobSubmission / Placement entity model cited above
• Bullhorn REST API documentation
• JobAdder developer API documentation