Why We Built Pickr: The Recruiting Problem Nobody Is Solving

I built Pickr because hiring teams make the same mistake on hire forty that they made on hire four, and nothing in their software notices. The typical applicant tracking system is an excellent filing cabinet and a useless colleague. Pickr exists to close that gap: recruiting intelligence that compounds instead of merely accumulating.

That is the short answer. The longer one includes the parts that still do not work, because a founder story made only of wins is marketing.

Both sides of the hiring table

I run ScalingPPL, a recruitment agency, and my background is in the Silicon Valley and European startup and scale-up scene. An agency has an invoice attached to every hire it gets wrong, and it sees both sides of the table: running the search, and sitting in the debrief with the client's own hiring team, who have to live with the person the agency sent.

The software on both sides of that table is not bad. Several applicant tracking systems are genuinely good. Greenhouse's process discipline is real, and a company that needs structured, auditable hiring at enterprise scale should buy Greenhouse. Ashby's reporting is the deepest available anywhere, and I say that as someone who competes with them. Bullhorn holds agency operations together at a scale nothing else touches, and an agency whose life is contracts, timesheets and back-office integration should stay on Bullhorn.

Not one of them gets better at hiring.

They get better at storing hiring. Every year the search is faster, the dashboards denser, the integrations broader. The quality of a team's judgement is the same in year four as in year one, because that judgement lives in people's heads and the software only keeps its output.

The rejection reason that tells you nothing

Picture a call every agency recruiter will recognise. A client's head of engineering asks about a candidate from the previous year. She has just seen him on LinkedIn as a staff engineer at a company everyone in the market can name, and she wants to know why he was passed over.

You open the ATS. The record is complete and completely useless. Name. Rejected at final stage. A date. A dropdown reason: "Not a fit."

The real reasoning did exist. Three people argued about him for four minutes on a Thursday debrief call, and the disagreement was genuine: scope of ownership against depth of systems experience. It lasted exactly as long as the call. What survived was three words from a dropdown menu.

Two weeks later the same client rejects a different candidate with the same three words, and nobody can put the two decisions next to each other and ask whether they were consistent, because there is nothing to compare. The system holds a perfect record of what was decided and no record at all of why, which means the organisation cannot learn from its own hiring even in principle.

Why interviewer feedback never arrives

The second frustration is one every recruiter knows. A real share of the week goes on chasing interviewers for feedback that never comes, and who owes what ends up tracked in a spreadsheet, because the reminders inside the ATS are ignored by everyone, recruiters included.

It looks like a discipline problem. It is not. Look at what you are asking a panel interviewer to do: three days after the conversation, from memory, log into a system she opens once a month and fill in an empty form that gives her nothing back. Of course it does not happen. In many teams she does not even have an account, because seats cost money and finance capped the licence count at the recruiters. So the feedback arrives as a Slack message or a sentence in a corridor, and it never touches the record.

That is why every interviewer in Pickr can file their own scorecard, which is most of the panel, because it is the only way the evidence ever gets captured. The mechanics of why scorecards fail in practice are worth a piece of their own, and I wrote one: the hiring manager scorecard guide.

Recording recruiting instead of doing it

The category was designed around custody, not judgement. Applicant tracking. The name is honest: track the applicants, keep the audit trail, prove you were fair. The recruiting itself stayed with the humans, and the software's contribution was a place to put the residue.

That was a reasonable design when software could not read a CV properly, could not listen to an interview, could not notice that two rejection reasons contradicted each other. It stopped being reasonable a while ago. Most of the rest of the stack has calcified around the same assumption, which is the argument in why the recruiting stack is broken.

What I actually wanted to build

Pickr is the AI-native recruiting system that treats every finished hire as evidence for the next one, so the reasoning behind a decision outlives the meeting it was made in.

Three things follow from that, and they are the whole product idea:

1. Evaluation belongs inside the process, not at the edges. Every candidate is scored continuously against what the role actually requires, on evidence of skills including related and transferable ones, rather than on which words appear in a CV.
2. Reasoning has to be captured at the moment it exists. Interviews are transcribed and scorecards arrive pre-filled with evidence mapped to each criterion, so an interviewer edits a draft instead of confronting an empty form on Friday. When someone rejects a strong candidate without a documented reason, Pickr asks for it while it is still in their head.
3. Outcomes have to come back. What happened to the people you actually hired changes how the next ones are evaluated. That holds whether you are an agency measuring which placements stayed or an in-house team measuring which hires grew, and the full shape of the idea is in the AI recruiting brain.

What Pickr has not solved

The problem	Where Pickr is today	Still on you
Reasoning evaporating after the debrief	Captured at the moment of the decision, tied to the criteria it relates to	Somebody still has to say the sentence out loud
Scorecards that never arrive	Drafted from the interview, for every interviewer on the panel	People who will not open any system at all
Keyword matching instead of evaluation	Continuous scoring on evidence of skills, related and transferable included	A brief that never defines what good looks like
Hiring that never improves	Outcomes of past hires feed back into how candidates are evaluated	Enough history, and enough hires, for the loop to mean anything
Reporting depth	Solid process reporting: time per stage, drop-off by stage, scorecard completion	Ashby is deeper. If reporting is the whole job, buy Ashby

Two of those deserve more than one line.

The first is cold start. The compounding is the entire premise, and compounding needs history. A team that arrives with no usable hiring record gets a good evaluation system and very little learning for the first months. Pickr imports your historical hiring data when you switch systems, and what comes across is usually thin: a stage, a date, a dropdown reason. You cannot reconstruct judgement that was never written down. For a search where you see five candidates and hire one person a year, the loop barely turns at all.

The second is harder, and I do not think anyone in this category has solved it. Learning from your outcomes means learning from your preferences, and your preferences contain your past mistakes. Evaluating on evidence of skills rather than pedigree helps. So does redacting personally identifying information from AI prompts by default, which is how Pickr runs, with candidate data hosted in Germany and the processing agreement included. Keeping the decision with a human, with the reasoning written down where a colleague can challenge it, helps most. None of that is the same as saying the problem is closed, and I would not trust a vendor who told you otherwise.

There is also a version of this where the software is not your problem at all. That is why the first thing we offer is a diagnosis rather than a demo: the free recruiting audit is a few questions and about two minutes with no signup, or a deeper read-only connection to your current ATS that turns your real hiring history into a report on funnel drop-off by stage, where you run slower than comparable teams, and how often scorecards actually get filled in. If it tells you the constraint is a process habit rather than a licence, fix the habit and keep the system you have. That is a cheaper answer than anything I sell.

I built Pickr because software that remembers everything and understands nothing is the wrong tool for the most consequential decision a team makes. If your hiring works, agency or in-house, if the reasoning behind your last forty decisions is written down somewhere a colleague could read it, and if your fortieth hire went better than your fourth for reasons you can name, you do not need us. If none of that is true, the question is not which system stores your candidates best. It is which one will still be teaching you something a year from now.