Skip to content
allanninal.dev/build
Collaborate

Part 1 of 7 · Background check chaser series ~6 min read

A background check chaser on AWS for a few dollars a month

Somebody accepts a job and a start date is agreed. Between those two things sit three or four checks, each owned by a different person, each with a different duration, and none of them visible in one place. Two weeks before the start date somebody asks how onboarding is going, gets a confident answer, and discovers on the Friday that one reference has not replied since the original request. This post walks through a small system that turns that into three clocks anybody can read.

A bell and sign on a display case
Photo by Donald Teel on Unsplash

Key takeaways

  • Each check is its own item, with its own owner and its own expected duration.
  • The system holds statuses only. Results live in HR records and never pass through it.
  • Chasing goes to whoever is actually holding it up, which is often not the candidate.
  • The useful output is one sentence: which check will not land before the start date.
  • Designed on AWS for about $2 a month.

The whole system on one page

Before any code, here is the shape of what we are designing.

System: check statuses in, a start-date prediction outThree boxes across the top sit outside the AWS account. On the left, Checks: the referees, the screening agency and the candidate, who between them own the outstanding items. In the middle, Check list: the types of check your business runs, who owns each and how long each usually takes. On the right, Whoever hires: the person who receives one sentence per starter. Each connects by an arrow to the AWS account container below. Status updates flow down into the account. The check list feeds in expected durations. A prediction of what will be late goes back out. Inside the AWS account are three components in a row. On the left, the Tracker, holding one item per check with a status and nothing else. In the middle, the Predictor, which asks whether each check will land before the start date. On the right, the Chaser, which contacts whoever is actually holding a check up. A note at the bottom says no check result ever enters this system, which knows only outstanding, chased and done.AWS ACCOUNTChecksreferees, agency,the candidateCheck listtypes, owners,usual durationsWhoever hiresone sentence per starterTrackerone item per check,status onlyPredictorwill it land beforethe start date?Chaserwhoever is holdingthis one upstatus updatesdurationswhat will be lateNo check result ever enters this system. It knows outstanding, chased, done.
Fig 1. Three things outside the account, three pieces inside it. The boundary at the bottom is the important one: statuses in, statuses out, and nothing sensitive in between.
  • App integration
  • Machine learning
  • Analytics
  • People

The boundary

It is worth stating the design’s most important constraint before anything else: this system never sees a check result. Not a disclosure certificate, not a reference’s content, not a right-to-work document. It knows that a check exists, who owns it, when it was requested, and whether it has come back.

That is not squeamishness; it is what keeps the system small enough to be worth building. The moment it holds a disclosure result it acquires a retention policy, a legal basis, an access control model, a subject access request path and a conversation with your insurer. Statuses have none of that, and statuses are where all the useful chasing lives.

What runs on every starter (the inside)

  • The tracker. Creates one item per required check when a starter is added, from the check list for that role. Each item has an owner, a requested date, an expected duration and a status. That is the whole model, and its simplicity is the point.
  • The predictor. Compares each outstanding item’s expected completion against the start date. The output is not a percentage; it is one of three words — comfortable, tight, or will not make it — because a hiring manager needs to act on it rather than interpret it.
  • The chaser. Contacts the owner of the specific item. A reference that has not come back is chased at the referee, not the candidate. A disclosure sitting with an agency is chased at the agency. Getting that right is most of the value, because chasing the candidate about something they cannot influence is both useless and unpleasant.

One starter, end to end

One new starter from offer to clearance, in five stagesA horizontal row of five boxes joined by arrows. Offer accepted: a start date is set. Checks created: four items with four owners. Predicted: three are comfortable and one is tight. Chased: at the referee who is holding it up. Clear: or a decision for a person to make. A note says the fifth box is a person's decision and the system never makes it.ONE STARTER, END TO ENDOffer acceptedstart date setChecks createdfour items, four ownersPredictedthree fine, one tightChasedat the refereeClearor a decision to makeThe fifth box is a person's decision. The system never makes it.
Fig 2. The same system as one line. Every stage except the last is bookkeeping; the last is deliberately left to a human.
  • App integration
  • Machine learning
  • Analytics
  • Front-end & mobile
  • People

In plain words

An offer is accepted on the 2nd with a start date of the 28th. Four checks are created from the list for that role: two references, a right-to-work verification and a standard disclosure. The references are owned by the referees, the right to work by the candidate, and the disclosure by the agency. Expected durations are five days, five days, two days and eighteen days respectively.

By the 12th, the right to work is done and one reference has come back. The disclosure was submitted on the 4th so it is due around the 22nd, which is comfortable. The second reference has had no reply in ten days against a five-day expectation, so the predictor marks it tight and the chaser emails the referee directly — not the candidate, who has no way to make their old manager answer an email. On the 16th the hiring manager gets one sentence: “One item at risk for K. Osei starting the 28th: reference from Ashford Ltd, requested 2nd, no reply, chased twice.” That sentence is the entire product, and it arrives twelve days before it would otherwise have become a problem.

Design rules that shaped every decision

  • Statuses only, never results. Holding a disclosure result would cost more in policy than the whole system saves.
  • One item per check, with its own owner. A single onboarding status hides which of four things is late and who can fix it.
  • Chase the person who can move it. Chasing a candidate about an agency’s backlog is useless and makes their first impression of you a nag.
  • Predict in words, not percentages. Comfortable, tight, or will not make it — because the reader has to act, not interpret.
  • The start date is a fact about a plan, not a deadline the system enforces. It never blocks anything.
  • A check that comes back is closed by a person, because “came back” and “is satisfactory” are different statements.

Why this shape

Pre-employment checks fail as a process for a specific and slightly unfair reason: the person with the most incentive to chase them — the candidate — is the person with the least ability to do so. They cannot make a referee reply, cannot escalate inside a screening agency, and are reluctant to nag anybody while they are still being onboarded.

So the design moves the chasing to the one party who can actually address each item, and it does so without asking anybody at your end to keep a mental model of four parallel clocks. The output is deliberately tiny: a sentence naming the item that will not land, twelve days before it becomes a Friday afternoon problem.

The next four posts walk through each piece: how a starter’s checks get created, how an update arrives without a result attached, how the prediction works, and how the chasing picks its target. One diagram per post, a cost breakdown, and an engineering reference at the end.

All posts