From AI-built prototype to production platform

The client

A recruitment firm whose team lives in their CV inbox. Their platform reads applications from several mailboxes, parses every CV with an LLM, and lets recruiters search, shortlist and email candidates.

Timeline

Started July 2026. Live in production September 2026. Ongoing monthly care since.

Our remit

Find and fix why the production platform was losing applicants and returning poor search results, add tests and CI, then run it. Same stack and hosting, no migration.

Stack

• TanStack Start (React)
• Supabase
• Netlify
• OpenAI
• Gemini
• IMAP / SMTP

The problem

The platform had been built quickly with an AI app builder. It worked in a demo, then struggled in production. Several ingestion paths had drifted apart, scheduled syncs were quietly running against the wrong place, some applicants never reached the system, search returned far too many loose matches, bulk email stalled mid-send, and there were no automated tests to catch any of it.

What we did

• Traced every failure to its root cause against live mail, not guesses.
• Collapsed the duplicate ingestion engines into one pipeline that reads each mailbox, parses CVs with an LLM (with a second model as fallback), and never silently drops an applicant.
• Rebuilt relevance and search on measurement, so recruiters see the candidates they actually asked for.
• Closed security gaps: mandatory encryption keys, enforced TLS on mail, and applicant details redacted from logs.
• Added a full automated test suite and CI where there was none, plus an alarm when a mailbox stops syncing.
• Kept them on their existing stack, with no migration, and now run it on a monthly care plan.

Architecture

One ingestion core reads every mailbox over IMAP on a schedule. Each mailbox runs in isolation, so a slow or failing inbox cannot starve the others. Messages are processed oldest-first in bounded batches with per-message timeouts, so a single bad attachment cannot stall the queue. Candidates land in Postgres, and search runs as a database function next to the data.

AI components

PDFs are text-extracted first, and only scanned documents fall back to vision OCR. An LLM turns each CV into a structured profile, with a second model provider as fallback. Truncated model answers are detected before parsing and retried rather than saved half-empty, and a relevance gate rebuilt against real mail keeps certificates and other attachments from becoming duplicate candidates.

Security

Credential encryption keys are mandatory, with no fallback. TLS is enforced on both incoming and outgoing mail. Applicant names and details are redacted from production logs, and an alarm fires when a mailbox stops syncing, so silence is treated as a fault rather than good news.

Measured results

Measured on the client's real mailboxes and candidate data, before and after the work.

• Real applicants silently discarded by the AI relevance filter

  Before

  About 1 in 11

  After

  None

• Share of the whole database matched by a search for one specialist role

  Before

  About 70%

  After

  Under 6%

• Automated tests

  Before

  None

  After

  499, run on every change