Contact
Detail A4Internal
In use

Hiring pipeline

We hire carefully, and we built the system that lets us. It reads every application, looks at real work as well as resumes, and people make every hiring decision. It keeps the team on your product strong, and it is the kind of practical AI we build for clients.

Applications4,500+1Read by the pipeline
Hiring forms17One system for every role
PeriodSep 2025 – Oct 2026And still running
Hires5+Made through it
Speed144 → 11Ranked in about 11 minutes

Note 1Counts are minimums. ↩

A–A
The problem

One job post brings hundreds of applications within a day.

142 of 144applications on day onefor one mobile developer role
Volume
Hundreds per post, within a day
Risk
Good people are easy to miss in a pile
Goal
Read everyone fast; people decide who is hired
B–B
How it works

Six stages. The machines read; people meet the candidates and decide.

From application to interview
S1

Custom form

Written answers instead of checkboxes

Automated
S2

Pre-filters

The basics first: salary range and experience

Automated
S3

Resume read

Every resume read in full

Automated
S4

Public work

Each developer applicant’s projects read alongside their resume

Automated
S5

AI scoring

Scored against the role’s own criteria: shortlist, maybe or not a fit

Automated
S6

Interview and practical

People meet the shortlist and set a real task

Human
Fig. 2 — The pipeline. Every role runs on the same system.
C–C
The work, in detail

Five things the pipeline does, and what changed.

Detail C1Screening
In use
C1

Reading every application

~11 minto a shortlist

144 mobile developer applicants ranked into a shortlist of 11. The top-ranked candidate was hired.

How we did it
Problem
Reading hundreds of applications by hand took days, so the later ones got less attention than the first.
What we did
The pipeline reads every answer and every resume, scores each applicant against the role, and ranks them. For writing roles it reads the samples too.
Outcome
144 mobile developer applicants ranked into an 11-person shortlist in about 11 minutes. The top-ranked candidate was hired. 91 writers screened, 79 of them read in full with their samples, in about 20 minutes.
Two rounds · timed
Content writers · about 20 minutes
Screened91
Read in full79
Top-rankedHired
Detail C2Real work
In use
C2

Real work counts

Everydeveloper applicant’s public code looked at

We look at each developer applicant’s public code alongside their resume, so their real work counts, not only how they describe it.

How we did it
Problem
A form and a resume only show how someone describes their skills.
What we did
The pipeline opens each applicant’s public code and reads it alongside their resume, so the work itself is part of the picture.
Outcome
Every developer applicant’s work is looked at, not only their resume.
What we look at
Projectswhat they built Historyhow it grew Skillsshown in the work Resumeread alongside
Detail C3AI use
In use
C3

AI use is welcome

Everyapplicant asked how they use AI

Using AI is fine. We ask every applicant how they use it, and we value a straight answer.

How we did it
Problem
Most people use AI in their work now, and we want to know how they use it.
What we did
The form asks every applicant directly how they use AI, and the answer is part of how we get to know them.
Outcome
A clear answer about how someone works tells us more than whether they used AI.
The AI question
AskedEvery applicant
Using AIFine
What mattersA straight answer
Detail C4Evaluation
Changed
C4

A practical round in every hire

Everyhire includes a real task

A polished application does not predict good work, so every hire now includes a practical round.

How we did it
Problem
A well-written form and a strong resume look the same whether or not the person can do the work.
What we did
We found that how an applicant looked on paper did not predict how good their work was, so a real task became part of every hire.
Outcome
A practical round is now part of every hire.
Process · revised
Practical roundOptional→Every hire
Detail C5Reuse
In use
C5

One system for every role

17hiring forms

All 17 hiring forms run on the same system. A new role reuses it instead of starting from scratch.

How we did it
Problem
Every role asks different questions and needs different checks. Building a screening system per role does not scale.
What we did
The stages are shared. Each role only sets its own form, its first checks and what it is scored on.
Outcome
17 hiring forms run on one system.
New role
Each role setsFormFirst checksWhat it is scored on
SharedEvery other stage
17 forms · one system
D–D
All work Next caseShopping Event VIP