Does it reject candidates on its own?

No. The screener never rejects anyone by itself. It sorts applicants into yes, maybe, and no piles and shows the hiring manager why for each one. A person reviews the piles and makes the actual call. Even a 'no' from the screener is just a suggestion the manager can overturn with one tap, and that override is logged.

How does it stay fair?

Three ways. First, it only judges against the job-related must-haves you wrote down, never against name, age, gender, school prestige, address, or photo. Those fields are stripped out before scoring. Second, every yes/maybe/no comes with the exact reasons from the resume, so a human can check the reasoning. Third, every decision is logged with the criteria used, so you can audit any hiring round later.

How much does it cost to run?

About $2.40/month at typical small-business volume (around 200 applications a month). The fixed cost is essentially zero. The variable cost is dominated by the one Bedrock read per application that scores the resume against the must-haves; Textract fires only when a resume arrives as a scanned PDF. At 1,000 applications a month the bill lands around $11.

Which AWS services does it use?

Lambda (Python 3.14, arm64) with Function URLs for the decision buttons, SES inbound for applications emailed in, S3 (with versioning), DynamoDB on-demand, EventBridge for routing, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) to read each resume against the must-haves, with Textract for scanned PDFs. No API Gateway, no NAT Gateway, no always-on compute.

Where do the must-haves live?

In a Google Doc in a Drive folder you control. One short rubric per role: the must-haves (each one a plain, job-related requirement), the nice-to-haves, and the pass marks for yes and maybe. A small drive-sync Lambda mirrors the rubric to S3 every 15 minutes; the screener reads from S3. Editing the rubric never needs a deploy.

For one job only: reading. Bedrock Haiku 4.5 reads the resume text and checks each must-have, quoting the line in the resume that meets it or noting that it is missing. The yes/maybe/no label itself is plain Python that counts met must-haves against the pass marks in your rubric, so the cut-off is yours and is the same for every applicant. The model reads; your rules decide.

Series · 7 parts Published May 23, 2026

Applicant screener

A serverless screener that helps a small team handle a flood of job applications fairly. It reads each resume against the role’s must-haves — which you write down — gives a clear yes/maybe/no with the reasons it found in the resume, and routes strong matches to the hiring manager with a short summary. A human makes every decision; it never rejects anyone on its own, and it sticks to job-related criteria only. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

01

An applicant screener on AWS for a few dollars a month

The whole system on one page — an intake, a reader, and a router, plus the one rule that keeps it fair: it sorts and explains, but a human always decides.
02

How an application gets read

Three lanes feed the queue — an apply inbox, a careers-form upload, and a job-board export. Each resume is turned into plain text, and the personal fields that don’t belong in a fair screen are stripped before scoring.
03

How an applicant gets scored

The reader checks each must-have against the resume and quotes the line that meets it. Plain Python counts the met must-haves against your pass marks and lands on one of three labels: yes, maybe, or no. The cut-off is yours.
04

How a strong match reaches the hiring manager

Strong matches get a short summary and land in the manager’s review queue. Four guardrails sit between a score and a routed candidate: dedupe, the fairness check, the summary, and the human review step.
05

How a hiring decision gets made

Three buttons on every candidate card: advance (move to interview), hold (park for later), and pass (with a reason). Every tap is the human’s call, and every tap is logged. The screener never decides.
06

What the applicant screener costs

A few dollars a month at small-business volume. One Bedrock read per application, Textract only on scanned PDFs, and no always-on parts. Where the dollars go and how the bill scales with applications.
07

Engineering reference: the applicant screener architecture

Same system, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs, Lambda inventory, IAM scopes, the SES inbound rule set, and the DynamoDB schemas.

What is an applicant screener?: A small serverless system that helps a small team handle a flood of job applications fairly. It reads each resume against the role’s must-haves, which you write down, gives a clear yes/maybe/no with the reasons it found in the resume, and routes strong matches to the hiring manager with a short summary. A human makes every decision; it never rejects anyone on its own and sticks to job-related criteria only.
Does it reject candidates on its own?: No. The screener never rejects anyone by itself. It sorts applicants into yes, maybe, and no piles and shows the hiring manager why for each one. A person reviews the piles and makes the actual call. Even a “no” from the screener is just a suggestion the manager can overturn with one tap, and that override is logged.
How does it stay fair?: Three ways. First, it only judges against the job-related must-haves you wrote down — never name, age, gender, school prestige, address, or photo. Those fields are stripped out before scoring. Second, every yes/maybe/no comes with the exact reasons from the resume, so a human can check the reasoning. Third, every decision is logged with the criteria used, so you can audit any hiring round later.
How much does it cost to run?: About $2.40/month at typical small-business volume (around 200 applications a month). The fixed cost is essentially zero. The variable cost is dominated by the one Bedrock read per application that scores the resume against the must-haves; Textract fires only when a resume arrives as a scanned PDF. At 1,000 applications a month the bill lands around $11.
Which AWS services does it use?: Lambda (Python 3.14, arm64) with Function URLs for the decision buttons, SES inbound for applications emailed in, S3 (with versioning), DynamoDB on-demand, EventBridge for routing, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) to read each resume against the must-haves, with Textract for scanned PDFs. No API Gateway, no NAT Gateway, no always-on compute.
Where do the must-haves live?: In a Google Doc in a Drive folder you control. One short rubric per role: the must-haves (each one a plain, job-related requirement), the nice-to-haves, and the pass marks for yes and maybe. A small drive-sync Lambda mirrors the rubric to S3 every 15 minutes; the screener reads from S3. Editing the rubric never needs a deploy.
Does it use AI?: For one job only: reading. Bedrock Haiku 4.5 reads the resume text and checks each must-have, quoting the line in the resume that meets it or noting that it is missing. The yes/maybe/no label itself is plain Python that counts met must-haves against the pass marks in your rubric, so the cut-off is yours and is the same for every applicant. The model reads; your rules decide.

All posts

Frequently asked questions

Other series