Three ways to get AI into your hiring. They cost different amounts, give you different control, and break in different ways. Most teams should choose the second.
The three options
| Build your own | Buy a tool | Use what you already have | |
|---|---|---|---|
| Time before it is useful | Months | Days | Hours |
| Control over the rules | Total | High | Limited |
| Ongoing cost | Developer time, forever | A subscription | Usually included |
| Who answers if it goes wrong | You | You and the vendor | You and the vendor |
| Breaks when | The person who built it leaves | You outgrow it | Your data is messy |
Building your own
Connecting an AI model to your own system is a weekend project and a two-year commitment. The weekend project is genuinely easy now, which is the trap. It demos well within a fortnight, and all the hard parts are still invisible at that point.
What is not easy: handling thousands of odd CV layouts, keeping records that satisfy a lawyer, deleting data when someone asks, testing for bias, and having someone free when the AI provider retires the version you built on.
One more thing. If you build it, you defend it. There is no vendor documentation to stand behind.
Worth doing if: you hire at unusual volume or in a field no tool serves, and you have developers spare. That is very few companies.
Buying a tool
You get software that has already met a thousand strange CV layouts, rules you control, and a company whose paperwork you can hand to legal. In exchange you accept someone else's idea of how a candidate should be described.
Five questions for the sales call:
- Can I see the data you pulled out of a CV, not just the score?
- Can you show me why this person ranked here, quoting their CV?
- Can I switch off "learn from our past hires" and use only my own rules?
- Can I export a full record of decisions, including the rules I used at the time?
- What happens to our candidate data if we leave?
If they cannot show you the extracted data, notice that. It usually means the ranking sits on top of something they would rather you did not inspect.
Using what you already have
Your current hiring system probably has an AI feature now. It is cheapest, needs no migration, and uses your existing data — which is the whole story.
If your system holds five years of duplicates and half-finished records, the AI feature will be confidently wrong in proportion. Built-in features also tend to be the shallowest version of each layer, because they were built to match a competitor rather than to be the main product.
Right choice if: your data is tidy, your volume is moderate, and you want to find out whether AI screening helps before spending real money finding out properly.
Five questions to decide
- How many applications do you handle each month? Under a few hundred, use what you have.
- Can you export a clean candidate record today? If not, fix that first. Everything depends on it.
- Who answers if a rejected candidate challenges the decision? If nobody, you are not ready.
- Will a developer still be here in two years and want to own this? If no, do not build.
- How would you get out of this choice later?
The order that works
Clean your data. Try the feature you already have on one real job. Then buy properly, once you know which layer was actually slowing you down. Teams who buy first usually discover the problem was their database all along.