A recruitment operation running on spreadsheets and a shared inbox now runs on one system that parses every CV, tracks every candidate through a configurable pipeline, and proves KVKK consent on demand.
Client context
The client is a Turkish technology and staffing company that recruits on behalf of enterprise employers across industrial, energy, and technology sectors. They run dozens of concurrent hiring projects, each with its own approval chain, and each producing hundreds of inbound CVs in mixed Turkish and English.
The client and their end customers are anonymised throughout this case study. Screenshots use pseudonymised candidate and project data.
The operational challenge
Recruitment agencies fail at the seams, not at the sourcing. This operation had five specific ones:
- Candidate data arrived from everywhere and settled nowhere. LinkedIn Recruiter, Kariyer.net, emailed CVs, and referrals each landed in a different place, with no shared record of who had already been contacted.
- Manual data entry was the bottleneck. Reading a CV and retyping it into a tracking system cost minutes per candidate — a cost that scales linearly with volume and introduces transcription errors.
- Pipeline state lived in spreadsheets. Nobody could answer "where is this candidate right now" without asking the recruiter who owned them.
- KVKK compliance was informal. Turkey's data protection law requires explicit, evidenced consent. It was being collected over email, with no timestamped record tying a consent text to a candidate.
- Reporting was reconstructed by hand at the end of each search, from memory and message history.
Product strategy
The product did not begin as an ATS. It began as a narrower CV-parsing tool that turned resumes into structured data — a single job, done reliably, already in production use.
The strategic decision was to treat that parser as infrastructure rather than the product. Parsing a CV is only valuable if something happens next. Extending the existing authentication, multi-tenancy, credit-metering, and file-storage layers into a full applicant tracking system meant the recruitment features could be built on proven foundations instead of rebuilt alongside them.
That reframing — from "CV parser" to "the system the hiring process runs in" — turned a utility into a platform.
The core solution
Recrou is a multi-tenant, bilingual (Turkish/English) applicant tracking system with AI embedded at four distinct points, not bolted on as a chat window:
- CV parsing — Google Gemini extracts structured candidate records from PDF and DOCX files, including multimodal PDF processing that recovers profile photographs. A faster model handles the common case; a stronger model is the automatic fallback on failure.
- Candidate–job match scoring — candidates are scored against a job description on a weighted rubric (skills 30%, experience 25%, role fit 20%, industry 10%, location 10%, education 5%), returning an A–E grade with per-category reasoning that cites specific CV evidence. The prompt is explicitly calibrated against grade inflation.
- Ask Recrou — recruiters query their own pipeline in natural Turkish or English; the model emits SQL, not prose. Every generated query passes a guardrail layer before execution.
- Executive reporting — a model-written candidate summary rendered into a branded, multi-page PDF for the hiring client.
Around that sit the parts that make it an operating system rather than a demo: configurable pipeline templates, stage-entry email automation, interview scorecards, offer and scheduling links, SLA monitoring, webhooks, audit logging, and a credit ledger that meters AI spend per tenant.
Primary workflows
Sourcing to structured record. A recruiter clicks a button on a LinkedIn Recruiter or Kariyer.net profile using the companion Chrome extension, or uploads a CV, or imports a CSV. The system checks whether that person is already active in another pipeline before creating a duplicate, queues the parse job, debits a credit, and produces a structured candidate.
Pipeline movement that automates itself. Stages come from templates — a short default pipeline or a full one with technical interviews, case studies, and reference checks. Two automations encode how recruiters actually behave: adding a note advances the candidate to Interview (forward-only, so it never drags someone backwards from a later stage), and marking a candidate unreachable emails them and returns them to Pre-Screening rather than dropping them out of the funnel.
Compliance as a first-class object. KVKK consent is requested through a tokenised public page, with the disclosure text, consent text, IP address, and timestamp stored as evidence. Consent status is a column in the candidate pool, not a note in someone's inbox.
My role
Sole developer and product owner. All 409 commits on the repository are mine, across a nine-month build. That covered product definition and specification, data modelling, backend and frontend implementation, the Chrome extension, AI prompt design and evaluation, KVKK compliance design, infrastructure and deployment, and direct customer feedback cycles.
Technical approach
Next.js 15 (App Router) and React 19 on TypeScript; PostgreSQL via Prisma with 48 models and 36 migrations; BullMQ and Redis for parsing and email queues; MinIO and Cloudflare R2 for documents; Resend for mail; full Turkish/English localisation.
Two decisions are worth a buyer's attention.
Authorisation is resolved per request, not baked into the session token. Permissions are two orthogonal axes — what a user may do (18 discrete permission keys, either from a system role or a fully custom role) and where they may do it (all company projects, or only projects they belong to). Resolving this from the database on each request costs one cached query and means a permission change takes effect immediately rather than after a token expires. In a system where an admin revokes access because someone left, that difference matters.
The natural-language query feature generates SQL behind a guardrail layer. Mutation keywords, statement chaining, comments, catalog tables, and dangerous functions are all rejected before execution; queries must target an allow-listed set of tables, must carry a LIMIT, and the tenant filter is bound as a parameter rather than interpolated by the model — so a prompt-injected query cannot cross a company boundary. Personal columns are excluded unless a user explicitly asks for names.
Outcomes
The system is the operational system of record for the client's recruitment: thousands of candidate records across dozens of concurrently active hiring projects, each carrying pipeline history, consent evidence, and an activity trail. Concretely:
- One searchable candidate database replacing per-recruiter spreadsheets and inboxes
- Automated CV-to-record intake from four sourcing channels
- Auditable KVKK consent evidence per candidate
- Stage history and SLA alerting that surface stalled candidates without asking anyone
- Per-tenant metering of AI spend, so cost tracks usage
No time-saved or revenue percentages are claimed here. The client has not published measured before/after figures, and inventing them would be worse than omitting them.
Need a similar product or workflow? I build AI-native internal systems — document extraction, multi-role B2B workflows, and compliance-evidenced data handling — from specification through production. Let's talk about what your operation still runs in spreadsheets.
