NexeraHR: an AI-powered ATS we design, build, and operate
Resume parsing, candidate matching, and screening workflows for SMB hiring teams, in production, run by the team that built it.
Context
NexeraHR is our own product: an AI-powered applicant tracking system aimed at small and mid-sized hiring teams. We are the client, the engineering team, and the on-call rotation, which makes it the most honest demonstration of how we build that we can offer.
The problem
SMB hiring teams drown in unstructured resumes and juggle screening across inboxes and spreadsheets, while most ATS products are priced and designed for enterprises. The engineering problem underneath: turn messy, inconsistent resumes into structured, comparable candidate data, reliably enough to base hiring workflows on it.
Constraints that shaped the build
- Resumes arrive in every format and quality level; the parsing layer has to normalize chaos without silently corrupting it.
- Hiring decisions are sensitive: the system assists screening, with humans making the calls, by design, not as a disclaimer.
- Built and operated by a small senior team, so operational simplicity (k3s, boring infrastructure) is a feature.
- Real-world integrations included biometric attendance hardware (ZKTeco devices), which do not care about your clean abstractions.
Architecture
The system, drawn honestly
Intake is the first line of defence: files arrive by upload, email, or connector, are content-hashed for deduplication across tenants, virus-scanned, and passed through a lightweight classifier that routes text-native PDFs, scanned PDFs (via OCR), DOCX, and pasted text down different rails. PII is scoped at ingest (encrypted at rest, tagged for retention, and gated by per-role access) because the cheapest place to make hiring data safe is before it fans out.
The parser is the pipeline's heart: an LLM-assisted extractor constrained by a strict, versioned schema, backed by deterministic rules for the fields where correctness must be exact (dates, phone numbers, emails, canonicalised titles, controlled vocabularies for employment type). Output is validated, typed, and written to a profile store with schema-version stamps so a rerun on a future model is directly comparable to today's. Matching consumes those typed profiles and ranks per role with the contributing evidence surfaced to recruiters. “Why is this candidate #3?” always has an answer.
Screening moves candidates through explicit stages with every state change recorded as a first-class audit event: who moved whom, when, on what evidence. Hiring decisions are human, by design, not as a disclaimer; the system's job is to compress the search so the humans decide on the shortlist that deserves attention. Every recruiter correction is captured as a labelled evaluation fixture; parsing accuracy is measured against that growing fixture set on every prompt or model change, and regressions fail the build before they touch a tenant.
Build notes
Decisions worth stealing
- Schema-first extraction: the parser is judged against a per-field labelled fixture set (thousands of real resumes), and a drop in field accuracy on any field type fails CI. “Vibes-based” parsing regressions do not merge.
- Deterministic normalisation lives before and after the LLM: dates, phones, emails, and titles are canonicalised by boring code that is fast, cheap, and correct every time. The LLM is reserved for the genuinely ambiguous work.
- Multi-tenant isolation is enforced at the database and query layer from day one: row-level scoping in every query, not a middleware afterthought. Retrofitting tenancy is the most expensive migration in SaaS.
- Every profile mutation and screening state change is an append-only audit event, so “what changed and by whom” has an answer without archaeology, and so subject-access and deletion requests are one supported operation, not a project.
- Per-role access controls apply to PII fields specifically: interviewers see less than recruiters, who see less than admins, enforced at the API. The UI cannot expose what the API refuses to return.
- ZKTeco biometric attendance integration is a resilient adapter with retries, dead-letter queues, and time-drift correction: real hardware protocols do not care about your clean abstractions, and the boundary layer is where you make them behave.
- Evaluation runs are pinned to schema and model versions, so a comparison against last quarter's fixture set is a valid comparison, not an accidental apples-to-oranges.
- What we would do differently: instrument time-to-shortlist and per-stage funnel from the first release. We added the measurement later than we should have, and had to rebuild trust in the numbers.
Results
What we measure
- Parsing field accuracy against the labeled fixture set
- Resumes processed per month across tenants
- Time-to-shortlist per role, before vs after AI-assisted screening
- Recruiter hours per hire spent in screening
We publish measured figures with source and date, or nothing. Instrumented numbers from production will appear here as they clear that bar. No estimates, no projections.