Case study
An AI hiring platform,
from voice to shortlist
Developers build a profile by talking for five minutes instead of writing a CV. Recruiters describe the role they need in plain English and get back a ranked shortlist. We designed and built both sides, and the code is public.
At a glance
Both sides of it
Want one of these for your own product? Book a technical call
The problem
Hiring developers breaks in three places
None of these are AI problems. They are product problems, and they are why the product works the way it does.
A CV is a bad way to judge an engineer
It is a document written to get past filters, so it fills up with the words a filter looks for and leaves out the things that tell you whether someone is right for your team.
Nobody wants to fill in the profile
Marketplaces lose people at the form. The profile stays half-finished, and a half-finished profile never shows up in anybody's search.
Searching for skills finds the word, not the person
Filter for React and you get a thousand people in no useful order. Everything you actually meant, the seniority, the timezone, the kind of product, never reaches the results.
How it works
A developer talks for five minutes
Five questions, answered out loud. Things like which technologies they work with day to day, and what kind of work they want next.
They check the profile it wrote
The answers come back as a filled-in profile. The developer fixes anything wrong and approves it. Nothing is saved before they do.
A recruiter describes the role
In ordinary language, including the parts no dropdown covers.
A shortlist comes back, with reasons
Ranked candidates, each with why they are on the list, and a shortlist to save the ones worth a conversation.
Scope
What a developer gets
- A profile built from five spoken answers, with a written form for anyone who would rather type
- A review step where they see every field before it is saved, and can change any of it
- A short intro video on their profile, plus a photo
- Role, seniority, location, availability, and the tech they actually work with
- Work history and certifications, each editable on its own
- GitHub, LinkedIn and personal site links, and full control to edit or delete the account later
What a recruiter gets
- A chat where they describe the role instead of assembling filters
- Ranked candidates with the reason each one was matched
- Search that reads intent, running alongside the hard filters that genuinely are yes or no
- A browsable feed of developer profiles with filters, tech badges, and full profile pages
- A live view of the search working through the pool, rather than a loading spinner
- A shortlist to save, review, and clear as they go
The parts that were not obvious
- Turning five minutes of talking into something publishablePeople restart sentences, correct themselves, and bury the useful fact in a story. Getting from that to a clean profile is genuinely hard, so we did not pretend otherwise: the system writes a first draft and a person approves it. That is why the profile is worth publishing and why nobody has to write it.
- Search that understands intent without going vagueMeaning-based search finds the right person for a description no filter could express, and on its own it will also happily return someone who is unavailable or in the wrong country. Both run together, so intent decides the ranking and the hard constraints still hold.
- Keeping results current when everyone edits their own profileThe moment someone updates their profile, search knows an old version of them, and nothing anywhere reports an error. So every edit marks that person for reindexing and the system tracks how many are currently out of date, which makes search quality something you can watch rather than something a user tells you about.
Read the code
Everything above is in public repositories, and reading them is the fastest way to check any claim on this page. The engineering decisions behind the hard parts are being written up separately.
The backend, in fulldevMatch-backend-fastapiWhat it proves
One product covering most of what a production AI build actually demands, from capturing audio in a browser through to a ranked shortlist a recruiter can act on.
- Voice and audio handled end to end, from recording in the browser to usable structured data
- AI that fills things in for people without being trusted to save them
- Search that ranks on meaning, over records that change every day
- An assistant that uses tools, finishes, and shows its work while it runs
- Video upload and processing that never blocks someone signing up
- Two full applications, one for each side of a marketplace, plus accounts and access
Building something like this? Talk to the engineers who built it.
Built with
The stack
Questions
Does the AI decide who gets hired?
No. It finds candidates, puts them in order, and says why each one is on the list. A person reads that and decides. The same rule runs through the whole product: it fills things in and a human approves them, including on the developer's own profile, where nothing is saved until they have checked it.
How is this different from searching a CV database?
A CV database matches the words someone wrote to get past filters. Here a recruiter describes the role in ordinary language, and that description is matched against what people actually do, alongside the constraints that genuinely are yes or no, like availability and location. What comes back is a short ranked list with reasons instead of a thousand rows.
Why ask developers to talk instead of filling in a form?
Because the form is where marketplaces lose people. Five minutes of talking produces far more than anyone types into a text box, and it moves the work from the person to the product: it writes the profile and they only correct it. Anyone who would rather type still can.
How do you stop it inventing things about a candidate?
By never letting it save anything. What it produces is a draft the developer reviews field by field before it becomes their profile. It can still mishear a company name or a framework, and the review step is where that gets caught.
Could this be built on our own candidate data?
The pieces travel better than the product does. Voice or document intake with a human approving the result, search that ranks on meaning over records that change constantly, and an assistant that returns a reasoned shortlist are all reusable. What changes per company is the data, which constraints are non-negotiable, and what counts as a good match, and that is the part worth spending discovery on.
Let's build yours
Our team contacts you within 24 business hours
We collect all the key requirements from you
The team of developers prepares estimation
We can sign NDA since we respect the confidentiality of our clients