Case Study Software services 12 min read

Recruitment sourcing: 1 week → 1–2 hours per role

Client: Ascendix (internal)

Ascendix internal: candidate sourcing dropped from ~1 week to ~1–2 hours. ~500 ranked candidates/day per researcher, AI-qualified with weighted criteria. Built in ~4 months.

Internal-verified. Built by our AI delivery practice for our parent group's own recruitment team. November 2025 – March 2026. Numbers reflect production telemetry against the internal pilot.

Executive summary

We built an AI recruitment platform for our parent group's own staffing and recruiting team. Six capabilities run as a single workflow: bulk job intake from the team's ATS, AI extraction of structured job-attribute requirements, position-based filtering against an enriched candidate database, AI evaluation that scores every candidate against weighted job criteria with written reasoning, profile-change signal detection that surfaces who is most likely to respond, and CSV export back into the ATS for personalized outreach.

The shift in plain numbers: the candidate-sourcing cycle dropped from roughly a week of manual research to one to two hours on the platform. A research team of four can now deliver around 500 ranked, AI-qualified candidates per day per researcher, exceeding the recruiter team's expectations. Manual sourcing previously produced about 200 candidates per researcher per week.

The reachable candidate pool, built from structured public-profile data, sits around 100,000 records, with the architecture sized for 500K. That is roughly a 10× expansion over the talent base manual sourcing could realistically cover. All-in run cost is approximately $11,730 per year, materially less than a single agency placement fee for a senior role.

The platform launched in production after about four calendar months by a fractional team using AI-enabled development. The methodology that compressed the build is its own case study: see Spec-Driven Development with AI .

The problem

Our recruiters lived at the top of the hiring funnel. Sourcing, the work of finding candidates worth contacting, consumed 15 to 20 hours of every researcher's week. The pattern is familiar to any recruiting team:

  • A researcher generated around 200 candidates per week for a single new opening, working manually through public-profile searches and copying details into the ATS.
  • Manual research stretched across days before the first candidate outreach. Time-to-first-interview ran 2 to 13 days depending on the role.
  • Recruiters acted as the sourcing bottleneck. The strategic work (evaluating fit, building relationships, closing) stayed compressed because the upstream funnel ate the calendar.
  • Candidate-job matching depended on subjective manual review. Two recruiters looking at the same profile reached different conclusions about whether to advance the candidate. Quality drifted.
  • Job-changing signals, the small profile updates that reveal someone is becoming open to new opportunities, went uncaught. Activity changes, profile-section edits, and self-declared availability indicators were scattered, and no system was watching them systematically.
  • Candidate data sat fragmented across the ATS and external profile sources. Nobody had a single, current source of truth.

None of this showed up as a quarterly disaster. It showed up as drift. Open positions stayed open longer than they had to. Recruiter time went into mechanics instead of judgment.

The solution

We built the platform as a 10-step pipeline organized in three phases. The recruiter-facing surface is a single web application; the work underneath is automated.

Phase 1: job setup. Recruiters bulk-import open positions from the team's ATS as a CSV file. The AI extracts structured attributes from each job description, the recruiter reviews and edits the extraction with a live matching-candidate count for feedback, and the position publishes from DRAFT to READY only after passing structural validation.

Phase 2: candidate selection. The recruiter narrows the enriched candidate pool with eight filter types (including a position-based auto-filter that applies the job's requirements as filter criteria in one click) and saves a long list of up to 500 candidates for the position, optionally excluding candidates already in other long lists for the same role to prevent duplicate outreach.

Phase 3: AI evaluation and outreach. The AI evaluates every candidate in the long list against job requirements: weighted evaluation criteria, a 0–100% relevance score with written reasoning, detection of profile-change signals scored by strength, and a confidence score that tracks profile-data completeness. Results sort by relevance with color-coded badges and export to CSV for direct import back into the ATS, where five custom fields carry the AI reasoning into personalized outreach.

The detail of each phase follows.

Phase 1 — Job setup with AI extraction

The AI parses each job description and pulls six attribute types:

  • Job title, mapped to a standardized list of ten titles (Software Engineer, Business Analyst, Project Manager, DevOps, Quality Engineer, Scrum Master, Data Engineer, Product Manager, UX Designer, System Architect)
  • Experience, minimum and maximum years
  • Skills, matched to an approved dictionary; unmatched terms flagged for review
  • Languages, with CEFR proficiency levels (A1–C2)
  • Certifications, matched to an approved dictionary; unmatched flagged
  • Seniority, one of Junior, Middle, Senior, Lead, or C-level

The recruiter reviews the AI extraction on a job-detail page that shows skills as visual badges (filled = required, outlined = preferred), languages with their CEFR levels, and a live matching-candidate count that updates as criteria are edited. Change a skill, see how many candidates match, decide whether to relax or tighten. Before the position publishes from DRAFT to READY, structural validation enforces a few rules: a job title is selected, at least one skill and one location are set, no unapproved skills or certifications remain. That keeps the matching dictionary clean across hundreds of positions.

Phase 2 — Candidate selection and long-list creation

The candidate database holds enriched profile data: name, location, recent job title (normalized, with the original title preserved), current company, up to five skill badges, an availability indicator, primary technology area, and the source link. Eight filter types are available:

  • Full name: Autocomplete after 2 characters
  • Country: Dropdown of all countries in pool
  • City: Dropdown of all cities in pool
  • Open availability: Toggle for self-declared availability
  • Skills: Multi-select with AND logic
  • Job title: Autocomplete matching normalized titles
  • Experience: Min/max years range
  • Primary area: Technology-domain classification

The position-based auto-filter is the workflow accelerator. The recruiter selects a published position, the platform applies the position's requirements (job title, required skills, country) as filter criteria in one click, and manual fine-tuning is available on top. Filtered views are shareable URLs.

Filtered candidates, up to 500, save as a named long list for a specific position. The exclusion feature lets the recruiter exclude candidates already in other long lists for the same position, with the count updating in real time (for example, "150 candidates (25 excluded)") to prevent duplicate outreach. Long lists track status through three states: New → In Research → Research Completed.

Phase 3 — AI evaluation, signals, and export

When research launches, the AI evaluates every candidate in the long list against job requirements through a seven-step process. It generates weighted evaluation criteria, scores relevance from 0 to 100% with written reasoning, detects profile-change signals, and assigns a confidence score that tracks how complete the candidate's profile is. Research runs in the background with a progress bar that updates as candidates complete (for example, "45/150 candidates, 30%").

Results return sorted by relevance score with color-coded badges:

  • 70–100%Color: Green — Meaning: Strong match
  • 40–69%Color: Yellow — Meaning: Partial match
  • 0–39%Color: Red — Meaning: Weak match
  • FailedColor: Gray — Meaning: Evaluation error

Expanding a candidate row reveals the full AI reasoning and signal explanations. Sorting by signal score surfaces candidates most likely to respond to outreach.

The signal-detection layer monitors fourteen profile-change patterns, each weighted by its strength as an indicator of openness to new opportunities. The strongest signals (an end date added to a current role, a recent avatar update, intent keywords appearing in profile copy, headline updates, personal contact info added in bio) score 8–10 points; weaker ones (background-banner change, education-date removal) score 3–4. Most signals require comparing current data against the previous data update, so they appear only after at least two refreshes have been recorded. Each signal expires after 90 days if it isn't re-detected.

Exports come in two shapes. The pre-research export carries basic candidate data for early outreach. The post-research export adds the full AI evaluation: relevance score, confidence level, AI reasoning, signal score, and signal reasoning. Files import directly into the ATS, where five custom fields (About, Relevance Score, Relevance Reasoning, Signal Score, Signal Reasoning) feed AI-informed personalized outreach.

What changed in production

The measurable shifts:

  • Sourcing time per role: ~1 week of manual research dropped to ~1–2 hours on the platform, covering the full cycle from position setup to a ranked long list ready for outreach.
  • Sourcing volume: ~500 candidates per day per researcher, ahead of the recruitment team's initial expectations. Manual sourcing previously produced ~200 candidates per researcher per week.
  • Reachable talent pool: ~100,000 enriched candidates, roughly 10× the base manual sourcing could cover, with architecture sized for 500K.
  • Candidate-page load: under 4 seconds at 100K records, which platform users confirmed as acceptable.
  • AI evaluation throughput: twenty candidates evaluated in about five minutes, which fits how recruiters work through long lists; the team has not raised performance complaints.
  • Evaluation consistency: every candidate runs against the same set of weighted requirements without exception. Manual review skipped or inconsistently applied criteria across recruiters. The AI doesn't.

What changed for recruiters: the time previously spent on mechanical sourcing reallocated to candidate engagement, relationship building, and judgment work. The platform doesn't replace recruiters. It removes the bottleneck that kept them upstream of the work they're best at.

Recruiter feedback collected during evaluation and UAT, a sample:

"I like the view of the dashboard — it's great to see key info about pipelines."

— platform user, recruitment team

"Profiles scored positively (70+) are generally relevant to the role."

— platform user, recruitment team

"I completely understand the idea and purpose of this tool."

— platform user, recruitment team

How we built it

About four calendar months by a fractional six-person team: two developers, a QA engineer, a business analyst, a project manager, and a solution architect. Allocation was uneven — the developer pair held the largest share of code-effort while the other roles ramped in around feature handoff points. Direct product-delivery effort came to ~1,300 hours across the engagement. The team integrated five application modules: API, frontend, end-to-end tests, ETL workflows, database. Twenty-two features shipped through the full specification process — including left-shift testing, with test cases authored from requirements before implementation — documented in our Spec-Driven Development case study .

We migrated the AI orchestration layer mid-project from an OpenAI GPT-4 model to Claude. Two reasons drove the call: better output quality on our extraction and qualification prompts, and the cost economics of the workload at scale. The system isn't vendor-locked. The provider can swap at the result/output layer without architectural redesign; switching takes engineering and testing effort but not a rebuild.

Run-cost economics:

  • Data ingestion & profile enrichment (initial)Initial (one-time): $1,650 — Monthly:
  • Ongoing data refresh & re-enrichmentInitial (one-time): — — Monthly: $555
  • LLM inference (research & qualification)Initial (one-time): — — Monthly: $100
  • LLM observability (Langfuse)Initial (one-time): — — Monthly: $50
  • Cloud compute, storage, networkingInitial (one-time): — — Monthly: $135
  • TotalInitial (one-time): $1,650Monthly: $840

Annual run cost: approximately $11,730. Materially less than a single agency placement fee for a senior role. The system is for internal use only, which simplified compliance scope. We ran a security review at project start with our security team. Infrastructure ownership: the development team owned setup and knowledge transfer; the IT department owns ongoing operations and management.

An automated quality-evaluation pipeline using Langfuse LLM-as-Judge ran against ~2% of outputs at launch. We paused it after a hosting migration; re-enabling at higher coverage is on the roadmap. In the interim, the QA team performs evaluation manually on demand. That's the kind of disclosure we wouldn't have made under a traditional consulting framing, but in honest internal-verified work it matters that we tell you which mechanisms are running and which aren't.

What we wouldn't claim

We wouldn't claim end-to-end recruitment metrics the platform doesn't directly control. Three of those (time-to-first-outreach, outreach response rate, hire-conversion rate) depend on recruiter behavior after the platform delivers candidate lists. Better candidate relevance and shorter long-list build time may move the numbers in the right direction, but the platform doesn't own them. The recruitment team is now tracking these metrics during active use; we plan a case-study update after three months of data.

End-to-end time-to-hire sits outside the system's direct measurability for the same reason. The platform compresses time-to-first-outreach by preparing a ranked list ready for contact in 1–2 hours instead of a week, but everything from outreach response onward sits in the recruiter's hands.

We tested up to 100K records in production and designed for 500K. We haven't formally benchmarked the 500K case. For datasets in the millions of records, a different storage backend would be the right migration path — designed for, not designed in.

We also wouldn't claim AI qualification replaces human recruiter judgment on the candidates that matter most. The AI surfaces and ranks. The recruiter still makes the call on who to talk to and how.

What this pattern unlocks for client engagements

The shape — bulk intake → structured AI extraction → human-validated criteria → AI evaluation with weighted criteria and written reasoning → signal-aware prioritization → push back into the system of record — generalizes well beyond recruitment. Any sourcing-or-screening-heavy function (sales prospecting, customer-support triage, partner-program qualification, support-case routing) has the same shape underneath.

Four-month delivery is possible because of the AI-enabled development methodology underneath. We document that separately in Spec-Driven Development with AI: 22 features in four months . If you're evaluating whether your team's bottleneck is the kind we can compress, a Pulse Check is the entry point. Free, thirty minutes, no slide deck.