Mark, Part Two
Three weeks ago, Mark texted me at 10:23 PM about a candidate his self-built AI screener scored 9 out of 10.
The candidate wanted $60K. The role paid $45K. Overqualified, wasted interview, a call that went nowhere.
I wrote about it here on Substack. Called it the strongest validation signal I’d gotten for the product I’m building, mostly because Mark found the gap himself, without me asking, while trying to solve his own problem.
This week, Mark sent me a voice note with an update.
He’s automated the next step. Any candidate his tool scores 8.0 or higher now gets an automatic drafted submittal to his client. No manual review in between the score and the send.
The compensation gap from three weeks ago is still not part of that score.
He didn’t connect the two. He just kept building, the way a resourceful person does when they’re solving a real problem with the tools in front of them.
Why this is a bigger deal than it sounds
A resume-fit score is answering one question: does this person look qualified on paper? Whether to submit them to a client right now is a completely different question, one that depends on salary alignment, timing, client feedback history, and a dozen contextual things a static score can’t see.
Mark’s tool is quietly merging those two questions into one automated action. And the automation moved faster than the underlying judgment did.
This isn’t a Mark problem. It’s an industry-wide one, and it’s currently playing out in federal court. Mobley v. Workday, the closely watched case alleging Workday’s AI hiring tools screened out applicants by age, race, and disability, just had a significant ruling on June 22, when a federal judge refused to dismiss most of the discrimination claims, letting the case proceed on key legal theories under California’s Fair Employment and Housing Act and the Americans with Disabilities Act.
One detail from that ruling stuck with me: the court is looking closely at whether automated screening tools use proxy indicators, like employment gaps, that can quietly correlate with a protected characteristic even when nobody designed them to.
That’s the exact same failure shape as Mark’s situation, just at a much bigger scale and with legal teeth. A system optimizes for one visible number. The thing that actually matters, and actually causes harm when it’s wrong, was never part of that number in the first place.
What I told him
I let him know the screener he originally saw from me was a one-day demo I built as a quick proof of concept, not the actual platform I’ve been building for three months. And I told him the market and compensation intelligence layer he just described wanting to add himself is already the thing I’m building into Recruiter OS.
Then, near the end of the same conversation, unprompted, he said this:
“Unless you want to build in also add comparative market analysis and the title of the position and where the range should be, which isn’t a bad idea, actually I might do that.”
He described my own roadmap back to me. Then told me he might just build it himself if I don’t move first.
The lesson for week two
The best product validation doesn’t always come from asking someone “would you use this.” Sometimes it comes from watching a real, resourceful user almost build your product by accident, twice, a week apart, hitting the same wall both times because nobody closed the gap in between.
Building/Learning in public. Week 2 of 12.