The Build or Buy Question Most Mid-Sized Organizations Answer Too Late
Most organizations don’t decide to outgrow their TA system. They wake up and realize they already have.
The signs show up quietly first. A recruiter builds a shadow spreadsheet because the ATS can’t track what the business needs to know. A hiring manager asks for a report that takes three people and two days to assemble. Then the signs show up loudly. The system can’t support a new business line. It can’t integrate with a tool the CHRO just bought. It can’t scale past the headcount the org just doubled to. By the time leadership notices, the conversation isn’t strategic anymore. It’s a fire drill, and fire drills produce bad technology decisions.
I’ve sat on both sides of this. At Activision Blizzard, my mandate was to hire a new team of 14 recruiters at various seniority levels and retool a TA function on Workday paired with Eightfold.ai. At Choice Hotels, I built an enterprise-wide TA model on Workday Recruit, running 100 to 120 concurrent requisitions with a lean team. At Internet Society, I inherited BambooHR, a system built for a much smaller global organization, and led the evaluation of what came next, weighing Workday, SAP, and Rippling against the org’s actual size and complexity. Three different organizations, three different answers, and the answer was never about which platform had the best feature list. It was about whether the organization had outgrown what it had, and whether anyone had defined what “outgrown” meant before the system told them.
This is the build or buy question, and most mid-sized organizations get to it backward. They start with a vendor demo instead of a definition of need. Here is how to do it in the right order.
Define what “outgrown” means before you’re living it
You cannot make a good build or buy decision in the moment a system fails. You can only make a good decision if you defined the failure conditions in advance.
Outgrowing a system usually looks like one or more of these:
Volume has surpassed what the platform or the team’s processes were designed to handle, and workarounds have become the actual process
The org has added complexity (new business units, new geographies, new compliance requirements) the system wasn’t built to support
Data lives in too many disconnected places, and no one trusts the reporting because no one agrees on which system has the right number
Integration needs have outpaced what the platform can connect to, so every new tool becomes a manual workaround
The system supports the TA function of three years ago, not the TA function the business needs today
Recruiters are sourcing and screening at a volume or speed the platform’s AI matching and automation can’t support, so the team is doing manually what a current system should be doing for them
If none of this is written down anywhere, the organization will find out it has outgrown its system the hard way, usually during a hiring surge or a board request for data nobody can produce cleanly.
AI belongs on both sides of this question. A legacy ATS or HRIS that can’t support AI-driven sourcing, screening, or matching is itself an outgrown signal, not a separate problem. And when the organization does evaluate what comes next, AI capability needs to sit in the evaluation criteria from the start, not get bolted on after the platform decision is made. The mistake is treating AI as a feature to ask about in a demo instead of a requirement to define before the demo happens.
When build makes sense
Build is the right call when the organization’s needs are specific enough that no platform on the market solves for them without heavy customization, and when the organization has the engineering capacity to maintain what it builds.
This is rare for mid-sized organizations, and it’s worth saying plainly. Most mid-sized companies are not differentiated enough in their TA workflow to justify the cost of building and maintaining custom infrastructure. The exception is when a piece of the workflow is genuinely a competitive advantage. At Activision Blizzard, pairing Workday with Eightfold.ai wasn’t about building from scratch. It was about layering a best-in-class sourcing capability onto a core system, because sourcing at that scale and speed was a real differentiator, not a commodity function.
Build, in practice, is more often this kind of targeted layering than a from-scratch system. True ground-up build belongs to organizations with the engineering bench to support it long term, and most mid-sized TA functions don’t have that bench, nor should they be spending their budget building one.
When buy makes sense
Buy is the right call for the large majority of mid-sized organizations, and the real decision isn’t build versus buy. It’s which buy.
The mistake mid-sized organizations make here isn’t choosing to buy. It’s choosing based on brand recognition or what a sister company uses, rather than what the organization’s actual size, complexity, and growth trajectory requires. A system sized for an enterprise of 50,000 employees will bury a 500-person organization in configuration overhead it doesn’t need. A system sized for a small business will buckle the moment that same organization adds a second business unit or a new compliance requirement.
This is exactly what played out at Internet Society. BambooHR had served the organization well at a smaller size, but the org’s complexity had grown past what it was built for. The evaluation against Workday, SAP, and Rippling wasn’t about finding the “best” system. It was about finding the system sized correctly for where the organization was and where it was headed over the next several years, not just where it stood that quarter.
The checklist that should exist before you sign anything
Most evaluations stall or go sideways because the organization never wrote down what it’s solving for. Here’s what should exist in writing before a single vendor demo happens.
Evaluation team and independence - Who is on the evaluation team, and do they have the standing to push back on leadership’s favorite vendor if the data says otherwise. A team stacked with people who report to the executive sponsor will produce the answer that executive already wants. Build a small team with real cross functional representation (TA, HRIS, IT, finance) and give them explicit permission to recommend something leadership didn’t expect.
Evaluation criteria, defined before you look at a single vendor - What does the system need to do, ranked by priority, not by what’s impressive in a demo. Cost, scalability, integration capability, AI-driven sourcing and matching, reporting and analytics, user experience for recruiters and hiring managers, vendor support and implementation track record. Score every vendor against this list, not against each other’s marketing.
Timeline with actual deliverables - A vague “we’ll evaluate this quarter” timeline produces a six-month process with no accountability. Set dates for requirements gathering, demo rounds, finalist selection, and decision, and assign an owner to each phase.
Defined success metrics - How will the organization know the new system worked. Time to fill, cost per hire, recruiter time spent on administrative work versus candidate engagement, data accuracy, adoption rate. If success isn’t defined before implementation, it can’t be measured after.
A defined end state - What does this system need to support three years from now, not just today. Mid-sized organizations grow, and a system that fits today but has no room to scale will trigger the same evaluation again in eighteen months.
An audit cadence - Once live, who checks that the system is being used correctly, that data is clean, and that the org hasn’t quietly built shadow workarounds again. Annual audits at minimum, with a clear owner.
Clear ownership and SLAs - Who owns the ATS versus the HRIS versus the integration between them. When something breaks, who is accountable for the fix, and what’s the expected response time. This needs to be documented before launch, not figured out during the first outage.
Stakeholders, champions, and adopters identified early - Every system rollout needs people who will actually use it well and model that use for others. Identify champions in TA and in the business before launch, not after adoption has already stalled.
A plan for when it breaks - Because it will. What’s the escalation path, who gets notified, and what’s the fallback process while the issue is being resolved. Organizations that skip this step end up improvising during outages, which is exactly the kind of workaround culture that got them here in the first place.
The real cost of getting this wrong
The cost of a bad build or buy decision isn’t really the licensing fee or the implementation cost. It’s the years of workaround culture that follow. Recruiters build their own tracking systems. Reporting becomes a manual exercise nobody trusts. The organization makes its next technology decision under the same pressure that made the last one rushed.
The organizations that get this right treat TA technology as infrastructure that needs periodic reassessment, not a decision made once and revisited only when something breaks. Build the evaluation discipline now, while the system still works, not later, when it doesn’t.
If your organization is asking whether it has outgrown its current system, or is about to choose what comes next, that’s the conversation to have before the vendor demos start, not after.
What this looks like in practice
Most organizations don’t need another full-time hire to get this right. They need someone who has run this evaluation before, who can sit down with TA, HRIS, IT, and finance in the same room and walk out with criteria, a scorecard, and a timeline with actual owners attached to it.
That’s the work ADVON does. We come in, define the evaluation criteria and decision framework before a single vendor demo happens, build the scorecard and RFP structure, set the SLAs and ownership model between ATS and HRIS, and identify the champions who need to be in place before launch, not after adoption stalls. We’ve run this from the inside at organizations using Workday, Eightfold.ai, BambooHR, and others, so we know where these processes typically break down and how to structure the evaluation so it doesn’t.
If your organization is mid-evaluation, about to start one, or living with a system everyone has quietly stopped trusting, that’s a conversation worth having now.
