Building a CV screening tool on a large language model is a two-week prototype and a two-year product. The prototype is genuinely easy, which is why so many teams start, and the gap between it and something you can defend to a candidate or a tribunal is where the cost actually sits. If your organisation has engineering capacity and a genuinely unusual requirement, building can be the right call. For most, the honest answer is no, and it is worth understanding precisely why before you spend the quarter finding out.
We sell the buy option, so weigh the argument accordingly. What follows is the list we would want if we were making this decision ourselves.
What the Prototype Does Well
Send a job description and a CV to a capable model with a well-written prompt, ask for a score and a rationale, and the output will be surprisingly good. On a handful of CVs it may be better than a tired human at the end of a long sift.
That result is real and it is also misleading, because it is measured on the easy part. The prototype is a demonstration that the model can reason about a CV. It is not a demonstration that you have a screening system.
The Seven Things the Prototype Does Not Do
1. Document Extraction at Real-World Quality
Candidates submit scanned PDFs, two-column layouts, tables, documents where the reading order is not the visual order, files in the wrong format and CVs embedded as images. Extraction quality determines everything downstream, and this is the single largest hidden cost. A model given garbled text reasons confidently about garbage.
2. Consistency Across a Large Batch
Run the same CV twice and you may get two different scores. That variance is tolerable in a demonstration and unacceptable in a ranking, because candidate 40 and candidate 400 must be assessed on the same basis. Controlling it requires deliberate work on determinism, calibration and reconciliation.
3. Defensible Output
A score is not a rationale. You need, per candidate per criterion, a statement of what was found and where it was found, exportable and readable by somebody who will challenge it. Under UK GDPR a candidate can make a subject access request, and the ICO's guidance on automated decision-making sets expectations about meaningful information on the logic involved. An internal score with no trail does not satisfy that.
4. Equality Analysis
The Equality Act 2010 applies to your selection process regardless of what produced it. Building your own means owning the analysis of whether the system disadvantages a protected group, doing it before deployment, monitoring it afterwards, and being able to show the work. That is specialist effort, not a sprint task.
5. Data Protection Engineering
Lawful basis, a completed data protection impact assessment, retention and deletion on a defined schedule, access controls, and a defensible answer about whether candidate data leaves the jurisdiction or trains anybody's model. Most prototypes send CVs to a third-party API in another country without anybody documenting that decision.
6. Domain Rubrics
A general model does not know that NHS Agenda for Change bands are not seniority labels, that CFA Level 1 is not a charter, that incorporated and chartered engineering status differ, or what a Single Central Record requires. Encoding UK frameworks correctly is slow, unglamorous and where most of the accuracy lives.
7. Operations
Queueing, retries, rate limits, cost controls, monitoring, model version changes that silently alter behaviour, and someone on call when a campaign stalls at nine in the morning.
The Honest Cost Comparison
Model inference is the cheapest line in the build. The expensive lines are engineering time to production quality, the specialist input for equality and data protection work, and indefinite maintenance including re-validation whenever the underlying model changes.
The cost that gets missed entirely is opportunity cost. Engineering capacity spent on a screening tool is capacity not spent on whatever your organisation actually sells. That trade is obviously right for a company whose product is hiring technology and usually wrong otherwise.
When Building Is Genuinely Right
Four situations, and they are narrower than they look.
- Your requirement is genuinely unusual. An internal taxonomy or assessment framework no vendor models, and which you are not willing to change.
- Screening is your product. If you are building something to sell, build it.
- Data cannot leave your environment at all. Some security postures permit no external processing, in which case a self-hosted build may be the only route. Note this is a reason to control the environment, not necessarily to write the application.
- You have durable capacity and an owner. Not a keen engineer for one quarter. A named team that will still exist in two years to re-validate after a model change.
A Middle Path Worth Considering
The decision is not binary. Where a vendor exposes an API, you can keep your own workflow, your own interface and your own data handling, and use the screening engine as a component. You own the integration and the experience; somebody else owns extraction quality, calibration, rubrics and re-validation.
That arrangement gets most of the control that motivates building without inheriting the parts that consume years. It is worth pricing before committing to a full build.
Questions to Answer Before You Commit
- Who owns this in two years, by name?
- What is our documented position on extraction failures, and how will we know they happened?
- How will we demonstrate consistency between the first and last CV in a batch of 300?
- Can we produce, today, a per-candidate rationale in response to a subject access request?
- Who has done the equality analysis, and when is it reviewed?
- Where is candidate data processed, and does anything train on it?
- What is our plan when the underlying model is deprecated?
A team that can answer all seven should probably build. A team that cannot answer three of them is describing a prototype, not a product.
Frequently Asked Questions
Is an Open-Weight Model Cheaper?
It changes where the cost sits rather than removing it. Self-hosting gives you data control and adds infrastructure, evaluation and maintenance burden. The application layer above it is unaffected either way.
Could We Build Just the Parsing?
Parsing is the hardest part to do well and the least differentiating. If you were going to build one component, this is the one to buy.
Does Buying Mean Losing Control?
Not if you interrogate the right things. Ask where processing happens, whether candidate data trains anything, whether rationales are exportable, and whether you can encode your own criteria. Those four answers determine how much control you actually retain.
How Long Does a Credible Build Take?
A prototype in weeks. Something you would put in front of a tribunal is a materially longer programme, and the timeline is dominated by extraction quality, calibration and compliance work rather than by the model.
What Is the Most Common Failure?
Shipping the prototype. It scores well, nobody can explain a ranking, a hiring manager loses confidence, and the tool is quietly abandoned after one campaign.
The Recommendation
Build if screening is your product, if your requirement is genuinely unmodellable, or if your security posture forbids external processing and you have durable capacity. Otherwise buy, and spend the interrogation effort on the vendor rather than the build.
If you want the control without the programme, look at the API route first. It is the option most teams overlook and the one that most often fits.
This article is general guidance, not legal or technical advice. Take specialist advice on data protection and equality obligations for any system you deploy.
Sources
Information Commissioner's Office. Rights Related to Automated Decision Making Including Profiling.
https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/rights-related-to-automated-decision-making-including-profiling/
Information Commissioner's Office. Guidance on AI and Data Protection.
https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/
Information Commissioner's Office. Data Protection Impact Assessments.
https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/
The Stationery Office. Data Protection Act 2018.
https://www.legislation.gov.uk/ukpga/2018/12/contents
The Stationery Office. Equality Act 2010.
https://www.legislation.gov.uk/ukpga/2010/15/contents
EU Artificial Intelligence Act. Annex III: High-Risk AI Systems Referred to in Article 6(2).
https://artificialintelligenceact.eu/annex/3/
InsightCircle
