Why Custom AI Is (Almost Always) a Bad Idea in Recruitment

It always starts with good intentions

‘We’ll build it ourselves. Then we’ll have full control.’ It sounds logical. Your recruitment process is unique. Your data structure is specific. Your clients expect a certain format. So why wouldn’t you build your own AI that does exactly what you need?

Because it almost always goes wrong. Not through lack of ambition or talent, but through a systematic underestimation of complexity, cost and timeline. It starts as a three-month project and ends as a black hole consuming talent, time and budget.

There is a second version of the same mistake, and it is the more popular one: don’t build the AI, bolt it onto the ATS you already run. That sounds cheaper and is usually worse, because you inherit every constraint of a system that was designed before any of this existed — and you now have two vendors pointing at each other when a field does not fill.

In this article I explain why building your own recruitment AI is a costly mistake in 95% of cases, why bolting one on is not the safe middle path it looks like, and in which 5% building genuinely makes sense.

The complexity you underestimate

‘We’ll take a speech-to-text API, add a summary prompt, and write it into our system.’ That simple on paper. In a demo from a developer who built it in a weekend, it looks impressive. Let’s walk through the actual complexity.

Problem 1: Speech recognition is harder than you think

Yes, there are speech-to-text APIs. Whisper, Google, Azure. They work fine. In English. In a quiet environment. With one speaker. On a good connection.

But in recruitment:

• You call in Dutch, German, French, or a mix. Mid-sentence the candidate switches to English. Or the client throws in a German word.
• You call from a mobile in the car, with road noise, wind and tunnels.
• Two people talk over each other in a Teams meeting. Or the candidate has kids in the background.
• The candidate speaks with an accent, a dialect, or very quietly.
• There are names, place names and company names that have to come out right. ‘Van der Linden-Pietersen’ is not trivial for a model.

The base accuracy of a speech-to-text API is 85-90%. For recruitment you need 95%+. That 5-10% costs months of work on domain vocabulary, error correction and evaluation. And you still do not have a system that behaves consistently across every channel and every condition.

Problem 2: Summaries aren’t ‘just a prompt’

‘Summarise this conversation.’ Anyone can write that prompt. In a demo it looks fantastic. But a usable recruitment summary is much more:

• The format has to match the conversation type. An intake is not a sales call. A client meeting produces different information than a follow-up with a candidate.
• It has to recognise and extract specific fields. Not ‘the candidate wants to earn 55,000’, but the number 55000 in the salary expectation field, with the right data type.
• It has to flag inconsistencies. The candidate says ‘3 years experience’ and later ‘5 projects in 4 years’. Which is it? The system should raise a hand rather than pick one.
• It has to know when to say nothing. If the notice period never came up, the field stays empty — because a plausible invented number is worse than a blank, and it is the kind of error that only surfaces in front of a client.
• It has to handle noise. Small talk, repetitions, ‘sorry, I was on mute’. Filtered out without losing anything that mattered.
• And it has to be configurable per client, per team, per recruiter, because client X wants a different shape than client Y.

Building one prompt that does all of that takes weeks of testing and iteration. Maintaining it as clients change and requirements accumulate costs months a year. And every update to the underlying model means testing it all again.

Problem 3: Writing into someone else’s system is a beast

This is where most projects — built or bolted on — get stuck. Sending data into an existing ATS or CRM is not ‘making an API call’. It is an integration project that does not end:

• Reading the field structure. Which fields exist? What type are they? What options are in the dropdowns? Which validation rules apply?
• Matching data to the right field. ‘Full-time’ matching the value ‘FT’ in a picklist. ‘Available by May’ matching a date format.
• Handling validation rules. Date formats that differ per instance. Numeric fields that reject text. Required fields that are not always available.
• Error handling. What if a field does not exist? What if the API errors? What if the system is offline? What if there is a conflict with a value somebody else just changed?
• Supporting more than one system. Bullhorn works fundamentally differently from the next vendor. Each integration is its own project with its own release cycle.

Building one native integration takes 3-6 months. Five of them? Count on 18 months and up. Then you maintain them, because APIs move, fields change and new versions ship. It is not a project, it is a standing obligation.

And here is the turn most buy-versus-build articles miss. That difficulty is not an argument for hiring someone who has already suffered through it. It is an argument about architecture: the pain comes from having two systems that both believe they hold the truth. Every reconciliation bug, every conflict, every ‘why is this field empty in the other system’ ticket comes from that one design choice. Which is why Simply does not do it either — writing data here means proposing a change on a record in the same system, which a human approves. There is no second copy to keep in step.

Problem 4: Capturing conversations across every channel

Recruitment does not happen in one channel, so capture has to cover online meetings, phone calls and the conversation across a table. Each has its own engineering problem:

• Capturing online meetings natively through Google and Microsoft means living inside their API requirements, which change. An update on their side can break yours on a Tuesday.
• Doing it with a meeting bot instead is easier to build and worse to use: it appears in the tile grid, and the first thing a candidate asks is what that account is.
• Phone and in-person capture means shipping and maintaining desktop and mobile software, which is a different discipline from building a web app.
• Consent, notice and retention rules differ per country, and getting that wrong is not a bug, it is a legal exposure.

This is not a weekend project. It is an entire product with its own compliance surface, its own maintenance and its own expertise.

The real costs

Let’s be realistic about money. Building a custom AI solution for recruitment requires at minimum:

• 2-3 AI/ML engineers (minimum 18 months): $350,000 - $700,000 per year
• 1-2 backend developers for integrations: $175,000 - $300,000 per year
• 1 product manager steering the project: $120,000 - $180,000 per year
• Cloud infrastructure and storage for audio: $35,000 - $90,000 per year
• Speech-to-text API costs: $25,000 - $60,000 per year (depending on volume)
• Model API costs at OpenAI or Anthropic: $12,000 - $45,000 per year
• QA and testing: $60,000 - $120,000 per year

Total first year: $775,000 - $1,495,000. And that is conservative. Most projects run 30-50% over budget and 6-12 months over time. That is not pessimism, that is the base rate of software development.

Compare that to a licence per user per month. Core is €79 and Professional €99 per user per month billed yearly, and there is no credits model and no markup on AI usage — you connect your own key and your provider bills you directly. With a team of twenty recruiters you pay a fraction of what building costs, you have it running next month rather than in 18 months, and someone else carries the maintenance.

The hidden costs nobody mentions

Beyond the direct costs there are the ones that rarely make the business case:

• Dependency on individuals. When your lead engineer leaves — and they do — you own a system nobody else understands.
• Technical debt. Quick fixes during the build become permanent. After a year you are inside a codebase that is expensive to change.
• Training and documentation. You have to teach your own team, write the docs and staff the support. That is somebody’s job, forever.
• Security and certification. ISO 27001 does not arrive as a by-product. It is a separate programme costing months and tens of thousands, and it has to be maintained, not achieved once.

When custom AI does make sense

There are genuine exceptions. Building can make sense if:

• You have a very specific use case no existing product covers and that configuration cannot reach.
• You have 500+ recruiters, where scale advantages start to outweigh the cost.
• You see AI as core business and intend to sell the result to others.
• You already have an AI team of five or more engineers with the expertise in house.

For 95% of recruitment companies none of these apply. And even then it is often smarter to take a product that already works and extend it through an API or a custom integration for the part that is genuinely yours. Why rebuild the boring 90% to get at the interesting 10%?

The alternative: buy and configure

The smartest approach for most companies is to buy something proven and configure it. Not build — configure. But that word only means something if you can say what is configurable, so here is the specific version.

With Simply that concretely means:

• Defining your own data model. Objects, fields and relations are metadata rather than code, so adding a field is a setting. It reaches the parser, the filters, the documents, the reporting and the API without a release. This is the part that replaces ‘we need custom software because our process is different’.
• Setting up summary formats that match your conversation types and clients. Configuration, not code.
• Connecting the six pre-built integrations — Gmail, Outlook, Google Calendar, Zoom, Slack and HubSpot. One OAuth flow per workspace, and the tokens are refreshed for you.
• Connecting your own AI key, so your provider bills you directly and there is structurally no margin for anyone to add. Inside the product you can see what each model and each action cost, in euros rather than tokens or credits.
• Building the rest on the public API, with its own keys and signed webhooks, for the genuinely bespoke 5%.

That does not cost 18 months and a million dollars. It costs a day of setup and an hour per adjustment, and someone else maintains, updates and improves it. Fourteen days, the full product, no card, if you want to test the claim before believing it.

The opportunity cost

The most underestimated argument against building is opportunity cost. Every dollar and every hour spent building AI is not spent on:

• Recruiting more candidates. More conversations, more placements, more revenue.
• Improving service to clients. Better service, higher satisfaction, more repeat business.
• Training your recruiters. Better interviewing, more placements per head.
• Growing the business. New markets, new clients, new services.

The question is not ‘can we build this?’. The question is ‘is this the best use of our time and money?’. For recruitment companies the answer is almost always no. You are a recruitment company, not a software company. Focus on what you are good at.

The ‘we want control’ argument

The most common argument for building is control. ‘We don’t want to depend on an external vendor.’ Understandable. But consider:

• You already depend on your ATS vendor. On your telecom provider. On Microsoft or Google for your email. Dependency is unavoidable in technology; the only question is which kind you choose.
• Building creates different dependencies. On your development team. On specific engineers. On a codebase only you understand, maintained by people you have to keep.
• The control you win by building (changeable code) you lose to complexity: harder to maintain, slower to update, more expensive every year.

Real control is not owning the code. It is three concrete things: a data model you define yourself rather than one a product manager chose for you, a permission model you can explain to a client, and an export path that gets your data out under the same rules that govern reading it inside — no hostage-taking, no bespoke extraction project.

Where Simply sits: it is the system of record

Worth stating plainly, because it is the opposite of what most tools in this category say. Simply is not a layer on top of your ATS. It is the ATS — the system of record, where the candidate lives.

That has consequences you should weigh before you agree with it:

• There is no write-back and no two-way sync with Bullhorn, Carerix or anything else in that category. Coming from another system is a one-way migration of about four weeks, including a field-mapping session where every current field gets a decision.
• Six connectors, named: Gmail, Outlook, Google Calendar, Zoom, Slack and HubSpot. Anything outside those is the public API.
• ISO 27001, with the certificate on request. No SOC 2 audit and no external penetration test — we would rather write that here than let a security review discover it.
• The platform and your candidate data are hosted in the Netherlands, on infrastructure we run. AI processing is a separate fact and stays separate: it runs in European regions, or on your own key with your own provider, and the models come from OpenAI and Anthropic.

None of that is a reason to build your own. It is the shape of the decision: you are not adding AI to the system you have, you are choosing a different system of record and configuring it instead of coding it. The honest comparison against what you run today is the right next step, and if it argues against switching, that is worth knowing now rather than in month four.

Want to see how it lands in your environment? Read how integrating AI into your ATS actually works, or get in touch for a demo with your own data on the table.