Build vs Buy ATS: A Staffing Agency Decision Framework
Every page you will read on this question was written by someone who gets paid for the answer. Bullhorn, TrackerRMS and TargetRecruit publish build-vs-buy guides that conclude you should buy — specifically, buy theirs. Offshore development shops publish the mirror image, and almost none of them has ever run a recruiting desk, chased a timesheet on a Friday, or explained a margin dip to a director.
So the disclosure first, because it is the only thing that makes the rest of this credible: First Bridge Consulting builds custom recruitment software. We also run a staffing desk. And our honest position is that most agencies reading this should buy off-the-shelf and stop thinking about it. If your desk runs under 25 recruiters on reasonably standard perm-and-contract workflows, a purpose-built ATS will beat anything you commission, on every axis except vanity.
What follows is the framework we use to work out which side of that line an agency actually sits on, including the scorecard.
TL;DR
- Buy is the default, and the default is usually right. Purpose-built staffing platforms already encode multi-client management, bill/pay spreads, redeployment and back-office integration. You are not paying for a database; you are paying for a decade of edge cases.
- Three narrow cases genuinely favour building: niche compliance credentialing, per-client bill-rate tier logic, and white-label branding you resell.
- Published market ranges are serious. RaftLabs puts a custom staffing-platform MVP at $140k–$230k over 14–18 weeks; GoHire argues a full ATS build can exceed $700k. Both have a stake in their own number, hence the range rather than a point estimate.
- The purchase price is the smaller number. Budget an ongoing engineering run-rate for maintenance, security patching and integration drift — indefinitely, not for a year.
- The middle path beats both extremes for most agencies: keep the ATS of record, build only the layer it does badly.
When does building an ATS actually make sense?
Three cases. We have not found a fourth that survives contact with a spreadsheet.
1. Niche compliance credentialing. Healthcare, aviation, security-cleared defence work, regulated trades. The workflow is not "attach a document" — it is expiry-driven and blocking. A nurse's licence, an immunisation record, a background check and a client-specific onboarding pack each carry their own expiry clock and their own renewal owner, and a lapsed credential must stop a submission and stop a timesheet, not generate a reminder email. Generic ATS custom fields model this as data; a credentialing desk needs it modelled as state. That gap is where agencies end up running a parallel spreadsheet — and in a regulated vertical, a parallel spreadsheet is a liability rather than an inefficiency.
2. Per-client bill-rate tier logic. Off-the-shelf systems handle a bill rate, a pay rate and a spread. They handle poorly the MSAs real agencies actually sign: rate cards banded by title and location, overtime at different multipliers per client, discount tiers triggering at cumulative headcount, tenure-based step-downs at month six, and markups that differ for W2, 1099 and corp-to-corp on the same requisition. Margin calculated outside the system is calculated late and calculated wrong. Agencies whose commercial model is the rate logic have a legitimate reason to own it.
3. White-label branding you resell. Not "our logo in the corner" — that is a theme setting. This is client hiring managers or partner agencies getting their own branded portal on their own domain, with the software forming part of what you sell. Vendor-permitted white-labelling is usually thin and priced accordingly. If you plan to license the workflow to boutique agencies, you are becoming a software company and should own the product. Notably, RaftLabs — which sells builds — names the same white-label trigger, alongside 50-plus recruiters and licence spend past six figures.
Everything else people cite as a build reason — "our process is unique", "the UI is clunky", "we want AI" — is nearly always a configuration, integration or training problem wearing a build costume.
The build vs buy ATS scorecard
Score each row honestly. Optimism here is expensive.
| Signal | 0 points | 1 point | 2 points |
|---|---|---|---|
| Compliance credentialing | Documents on file, no expiry logic | Some expiry tracking, manual chasing | Expiry state must block submission and timesheet |
| Bill-rate logic | Flat markup, one rate card | A few client-specific rates | Tiered, banded, tenure-stepped rates per MSA |
| White-label | Internal use only | Client portal with our branding | We resell the platform to third parties |
| Scale and licence spend | Under 25 recruiters | 25–50 recruiters | 50+ recruiters, licence spend is a board line item |
| Engineering capacity | No in-house engineers | One developer or an agency retainer | A standing product team we already fund |
| Integration surface | Email and a job board | Payroll plus accounting | Multiple VMS feeds, payroll, accounting, background checks |
| Off-the-shelf fit | Two vendors demoed well | One vendor fits after configuration | We ran a real trial and it structurally failed |
| Tolerance for a 4–6 month gap | We need this quarter | We can wait two quarters | We can run current systems for a year |
0–5 — Buy. Configure hard, integrate properly, and spend the saved money on recruiters. A build will not pay back.
6–10 — Buy the system of record, build the layer around it. This is where most agencies with a genuine gap actually sit, and it is the answer this post exists to give. More on it below.
11–16 — A full build is defensible. Scope it as a product with an owner and a roadmap, not as a project with an end date.
What do you lose by leaving Bullhorn?
More than teams expect, and most of it is invisible in a demo.
The ecosystem, not the software. The value of an entrenched platform is the surrounding market: job-board posting, parsing, background checks, e-signature, payroll and VMS connectors, plus a partner network that already knows the data model. Bullhorn publishes a developer portal and runs a marketplace precisely because that gravity is the product. Leave, and every one of those connectors becomes a line in your backlog with your name on it.
Domain defaults you did not know you relied on. Redeployment prompts before a contract end date. Duplicate detection that understands the same candidate arriving through three sourcing channels. Per-client submission formatting — the blinded CV, the client's own template, the required field ordering. Timesheet-to-invoice with approvals, adjustments and credit notes. Gross profit per placement as a first-class reporting number rather than a spreadsheet export. None of that is hard to describe. All of it is expensive to rebuild, and you rebuild it in production, on live placements.
Your reporting history. Migrating candidates and clients is routine. Migrating years of activity data — submissions, interviews, placement history, the timeline that makes redeployment possible — is where migrations quietly lose fidelity, and the loss surfaces months later when someone asks why fill rates look different.
Leverage. Vendors compete for renewals. Your own build never gets cheaper because a rival cut prices.
How much does a custom ATS cost to maintain?
The build quote is the entry fee. Plan for these as permanent line items:
| Ongoing cost | What drives it | Why it never reaches zero |
|---|---|---|
| Maintenance engineering | Feature requests, bugs, small workflow changes | A live desk generates requests weekly, forever |
| Security patching | Framework, library and OS CVEs | You hold candidate PII; patch latency is your liability |
| Integration drift | Job boards, VMS, payroll, accounting APIs | Third parties version and deprecate on their schedule, not yours |
| Hosting and monitoring | Uptime, backups, restore testing | Recruiters cannot work when it is down |
| Compliance | GDPR/DPA requests, access reviews, client security questionnaires | Enterprise clients audit their suppliers |
| Eventual replatform | Framework EOL, the rewrite in year five or six | Software you own ages the same way software you rent does |
A common industry rule of thumb puts annual maintenance somewhere in the region of 15–25% of the original build cost. Treat that as a planning band rather than a quote — the real driver is integration count and compliance surface, not lines of code. The decision that matters is not "can we afford to build it" but "can we afford to fund it every year from now on". Agencies that regret a build almost always regret the run-rate, not the launch.
Can we build only part of it?
Yes — and for agencies scoring 6–10 this is almost always the right answer.
Keep the commercial platform as the system of record. Build the specific layer it handles badly, against its API:
- A credentialing service that owns expiry state and blocks submissions, syncing status back to the ATS.
- A margin and rate engine that applies per-client tier logic and reconciles timesheet-to-invoice, so gross profit is correct on the day rather than at month end.
- A client submission portal with per-client formatting and branding, replacing the emailed CV pack.
- VMS submission automation for Fieldglass, Beeline and similar, where the manual re-keying tax is measured in recruiter hours per week.
This wins on four counts: it costs a fraction of a platform build, it lands inside an existing operations budget rather than requiring a capital decision, it keeps vendor support and the connector ecosystem intact, and if it fails you switch it off and nothing stops. It is the shape of most of the work we take on in custom recruitment software, and the shape we recommend when a full build would be indulgent.
What happens if the dev shop disappears?
Ask this before you sign, because it is the risk with the highest cost and the lowest visibility.
- Own the repository from commit one. Your organisation, your cloud account, your domain registrar — not the vendor's, with a promise to transfer.
- Put IP assignment in the contract, enforceable in the developer's jurisdiction, not just yours.
- Require a runnable environment a third party can stand up from documentation alone. Test it once with someone who did not build it; this single exercise finds more continuity risk than any clause.
- Insist on mainstream technology. .NET, Java, React, PostgreSQL. A clever niche framework narrows the pool of people who can rescue you.
- Ask who the single point of failure is. On small builds it is usually one engineer. That key-person risk is identical if you hire in-house — one developer leaving takes the only mental model of your rate engine with them.
Continuity risk is not an argument against building. It is an argument against building carelessly, and it is answered contractually and architecturally rather than with trust — the same due diligence that applies to scoping any custom software development engagement.
FAQ
Should we build our own applicant tracking system? Probably not. Build only if you score 11 or higher on the scorecard above — that means blocking compliance credentialing, per-client rate tier logic, or white-label resale, plus the engineering capacity to fund it permanently. Otherwise buy, configure properly, and build only the missing layer.
How much does a custom ATS cost to build? Published market ranges vary widely because scope does. RaftLabs cites $140k–$230k for a staffing-platform MVP in 14–18 weeks; GoHire argues a full build can exceed $700k. The real drivers are integration count, parsing accuracy targets, compliance surface and whether you need multi-tenancy — not headcount or geography.
Is a homegrown ATS cheaper than a commercial one over five years? Only at scale. Compare licence spend against build cost plus annual maintenance, hosting, security patching and the replatform you will eventually fund. At 50-plus recruiters with heavy licence spend the arithmetic can favour building; below roughly 25 recruiters it rarely does.
Custom ATS vs off-the-shelf — what actually differs day to day? Off-the-shelf gives you the ecosystem: connectors, parsing, compliance updates and a roadmap you do not pay for directly. Custom gives you exact workflow fit and no per-seat fee, in exchange for owning every future change yourself.
Can we migrate off a custom build later? Yes, and you likely will — most software has a replatform in its future either way. Make it survivable now: clean relational schemas, documented exports, a genuine data dictionary, and no business logic buried in database triggers.
Weighing a build against another year of licence fees? First Bridge Consulting runs a staffing desk and builds recruitment software, so we will tell you plainly when the answer is "renew and configure it properly". If a build or a bolt-on layer is genuinely justified, we will scope it against your actual workflows. Talk to us about your ATS decision → or email success@firstbridgeconsulting.com.
Related reading: Contract Staffing services · Custom Recruitment Software · Shopify App Development Cost 2026