How I Built an Enterprise AI Recruiting Platform
The architecture behind TalentPike — multi-tenant SaaS, semantic matching, explainable ranking and a local LLM keeping candidate data in-house.
Recruiting software is deceptively hard. On the surface it's "match resumes to jobs." Underneath, it's a multi-tenant data problem, a search problem, an explainability problem, and a security problem — all at once. Here's how I approached building TalentPike, an enterprise AI Applicant Tracking System.
Start with tenancy, not features
The first decision was the most important: row-level multi-tenancy. Every table carries a tenant_id, every query enforces it, and per-tenant storage prefixes isolate files. This is far easier to get right on day one than to retrofit later.
Turn resumes into structured data
Raw resumes are unusable for ranking. A local LLM (Ollama) parses each resume into structured entities — skills, titles, employers, experience — while keeping sensitive PII inside our own environment.
Match by meaning, then explain it
Candidates and roles are embedded into a vector space using pgvector. But a raw similarity score isn't trustworthy to a recruiter. So the final score is a hybrid: semantic similarity plus structured signals (skills, seniority, recency), and every ranking ships with a human-readable rationale.
What I'd tell my past self
- Design security and tenancy before anything else.
- Explainability is a feature, not a footnote.
- A local LLM can be the difference between a demo and a deployable product.
This is a placeholder draft — the full article is coming soon.