AutoRecruit: the whole hiring pipeline, posting through onboarding
A recruiter portal backed by eight n8n workflows, built around one rule: in hiring, a confidently wrong automated rejection is the worst possible failure, and this system is built so it cannot happen quietly.
LIVE · 6 OF 8 WORKFLOWS ACTIVE · HUMAN GATE AT SCREENING
- Sector
- HR and recruitment
- Basis
- Own product build
- Stack
- n8n · Gmail · Sheets · Drive · Hunter · LLM · Discord
- Surface
- Recruiter portal + 8 workflows
- Status
- 6 of 8 workflows running live
The problem: a hiring pipeline that leaks at every stage
Hiring is a pipeline that leaks at every stage. Job postings live in one place and applicants in another. Resumes arrive as email attachments someone has to open and judge one at a time. Candidates go quiet because a follow-up never went out. And by the time anyone asks why time-to-hire is climbing, the data needed to answer sits scattered across inboxes and spreadsheets.
The approach
One recruiter portal on top, eight n8n workflows underneath: candidate sourcing, applicant intake, job-posting intake, resume screening, trial submission, status changes, offer acknowledgement and pipeline management. Four engineering decisions separate it from a demo:
-
Ambiguous cases go to a human, not to a guess
The resume screener routes anything it cannot read confidently down a separate path that pings a person, instead of forcing a score it cannot justify.
-
Intake is idempotent
New applicants are matched on email: if the record exists it updates, if not it creates. A form submitted twice does not produce two candidates.
AUTORECRUIT / N8N / APPLICANT INTAKE LIVE
FIG. 01 Applicant intake. Matched on email, so a duplicate submission updates the record instead of creating a second candidate. -
Deduplication before enrichment, not after
The sourcing workflow checks whether a record already exists before spending an enrichment API call on it, so re-runs cost nothing extra.
AUTORECRUIT / N8N / SEARCH INTENT SOURCING BUILT, NOT ACTIVE
FIG. 02 Sourcing, built and not currently switched on. The existence check runs before the enrichment call, so a re-run never pays twice for the same record. -
A token-limit check before the model ever sees the document
Oversized files are filtered out rather than blowing up mid-run or quietly costing a fortune. The same cost-ceiling discipline runs through everything I build.
The system
How it fails safely
| Failure | What happens instead |
|---|---|
| Unreadable resume | Routed to a human review path with a notification. The system never forces a score it cannot justify. |
| Duplicate form submission | Intake matches on email and updates the existing record. Two submissions, one candidate. |
| Oversized document | Filtered by a token-limit check before the model sees it. No mid-run blowups, no surprise API bill. |
| Sourcing re-run | Deduplication runs before enrichment, so a repeat run spends nothing on records it already has. |
Result
- One recruiter portal replacing job postings, applicant tracking, screening and reporting spread across separate tools.
- Resume screening automated end to end, with an explicit human-review path for anything uncertain.
- Six of eight workflows running live, covering intake, screening, status changes, offers and trial submissions.
- Recruitment metrics available as a live view rather than a manual monthly rebuild.
Built by Hisham Hanawi. This is an operations automation build.
Related, but a different build: the recruitment retrieval layer answers candidate questions from a grounded knowledge base. This system moves candidates through stages.
A pipeline leaking somewhere?
100% JOB SUCCESS · TOP RATED PLUS · 583 HOURS / 6 ENGAGEMENTS
Source: Upwork profile, verified 2026-08