Applicant tracking systems were designed to file PDFs, not evaluate talent. Here is why the modern hiring loop leaves both employers and candidates in the dark, and why that tradeoff is no longer acceptable.
If you have hired recently, you know the loop. You write a job description, post it, and 300 applications arrive. Your ATS gives you a keyword search over a pile of PDFs. So you filter, you skim, you make a shortlist from the first forty CVs you had the energy to open, and you tell yourself the other 260 probably were not a fit.
If you have looked for a job recently, you know the other side of the same loop. You tailor your CV, you apply, and nothing happens. No response, no rejection, no signal at all. You were never rejected. You were never read.
Both experiences come from the same design decision, made decades ago and never revisited: applicant tracking systems were built to store applications, not to understand them. They are filing cabinets with a search bar bolted on. Everything that actually matters, deciding whether this person can do this job, was left to a human skimming under time pressure.
That was a reasonable tradeoff when the alternative was nothing. It is not reasonable any more.
What we think the job actually is
Hiring is a matching problem. On one side you have a role, which is a messy bundle of requirements, some written down and some not. On the other you have people, whose real capability is buried in unstructured documents written in a hundred different formats. The work is connecting the two.
Keyword search cannot do that. "Senior Python engineer" does not match the CV of someone who spent four years building data pipelines in Django and never used the word "senior" about themselves. Every hiring team knows this and works around it by reading more CVs, which does not scale, or by narrowing the search, which just means missing people earlier.
The technology to get this right exists now. Not "AI will replace recruiters", which is not what we believe and not what we are building. Something narrower and more useful: actually read the documents, truly understand the role, and put the right forty CVs at the top instead of a random forty.
What we built
BYOUR is that system. In practice it means three pieces of engineering:
Extraction. Every CV becomes structured data. Experience, skills, education, certifications, tenure, progression. Not a blob of text with a filename, but a record you can actually query.
Vectorisation. Candidates and roles both become vectors in the same space, which is what makes real matching possible. Not "does this CV contain this word", but "how close is this person to what this role needs".
Minerva. The AI layer on top. She scores and shortlists, and then, importantly, she stays in the conversation: a hiring manager can ask why a candidate scored the way they did, push back, get interview questions drafted, and work the pipeline with her rather than around her.
All of it runs in production on AWS today, with companies onboarding now.
What comes next
Everything above serves the company side. The candidate side is the half of the problem nobody has bothered to fix, and it is what we are building next: a place where your profile stays current, where roles are matched to you rather than the reverse, and where applying means being actually read.
That is not a small claim, and we would rather show it than announce it. So we will.
What this newsletter is
Not a product changelog and not a marketing list. This is where we write about the problem we are working on and what we are learning while we build. Some issues will be technical, about the architecture and the tradeoffs and the things that did not work. Some will be about the hiring market itself, from the seat of a company that both builds the software and runs live searches.
If you hire, or if you are looking, or if you just find the engineering interesting, you are in the right place.
We will see you in the next one.
Marcus Moura, Co-Founder and CTO, BYOUR