Build a Custom AI System to Screen and Rank Candidates

Most small recruiting firms rely on the built-in filtering tools within their ATS. These are simple keyword matchers, not AI. A search for "product manager" will miss a great candidate whose resume says "led product development" because it cannot understand semantics. This forces recruiters to spend hours manually reading through hundreds of resumes for every open role, defeating the purpose of the software.

Third-party screening tools like Ideal or HireVue offer more advanced analysis but come with two major drawbacks for SMBs. First, they charge per-seat, per-month fees that become expensive for a 10-person team. Second, their models are black boxes trained on generic, global data. They cannot learn that for your specific client, experience at one of their three main competitors is the single most important hiring signal.

Consider a 15-person firm using their ATS's built-in "AI matching" for a "Senior Python Developer" role. The system flags 150 resumes containing the word "Python", but the real requirements are experience with FastAPI and payment gateways. A human must still read all 150 resumes to find the 3 qualified candidates. This so-called automation saved zero time and created 4 hours of low-value work.

Syntora's approach to building a candidate screening system begins with an initial discovery phase to understand your specific hiring criteria and ATS setup. We would start by integrating with your ATS API (e.g., Greenhouse, Lever, Ashby) to understand your data schema and past application data. This historical data, including resumes and hiring outcomes, would be used to inform the development of your custom ranking model.

For document parsing, the system would utilize the Claude API to process each resume. We've built document processing pipelines using Claude API for financial documents, and the same pattern applies to recruiting documents, enabling the extraction of key features like skills, experience, and employers into a structured JSON object. This data would then be stored in a Supabase Postgres database.

The core of the system would be a custom ranking model developed in Python. This is not a generic neural network but a series of weighted rules and heuristics collaboratively defined with your team. This logic would be deployed as an AWS Lambda function, which typically offers cost-effective hosting. The model would first apply essential knock-out rules (e.g., work authorization) and then score remaining candidates based on the job's unique requirements.

The screening logic would be exposed via a FastAPI endpoint. Upon a candidate's application, a webhook from your ATS would trigger the Lambda function. The API call would return a comprehensive output, including a candidate score, confidence level, and a concise summary of strengths and weaknesses. This information would be written back to custom fields within your ATS, making the screening output visible directly within the recruiter's existing workflow.

For ongoing refinement, the system would incorporate a feedback mechanism. Recruiters could flag instances where the model's assessment diverges from their judgment. This feedback data would be logged in Supabase and used during periodic tuning sessions to adjust scoring weights, allowing the system to learn and improve based on real-world hiring outcomes. A typical build timeline for a system of this complexity is 6-10 weeks, depending on the initial data readiness and the depth of custom logic required. Deliverables would include the deployed and integrated scoring system, source code, and documentation for ongoing maintenance. The client would primarily need to provide access to their ATS, define their specific hiring criteria, and participate in feedback loops.