Ryger
Live · Web
A recruiter-owned talent network, discovered one workflow problem at a time.
Ryger didn’t start as a recruiting product. It started as a question about why both sides of hiring kept missing each other — and every answer changed what it should be. What follows is the sequence of discoveries that turned a matching tool into a network, and the evidence-first assessment system underneath it.
The short version
Each discovery moved Ryger further from “build a better match” and closer to “build the asset recruiters actually keep.” The matching engine was never the point. The network was.
- Role
- Founder / AI Product Builder, Yellow Labs Products
- Timeline
- 2025 – present
- Status
- Live at ryger.app
- Live
- ryger.app ↗
Key signals
- Per-requirement Met / Review / Missed, each verdict citing real evidence
- Every number and date in a generated resume traced to source evidence
- Seven discoveries from matching tool to talent network
Capabilities shown
- Product discovery
- Workflow design
- Vector retrieval
- Explainable AI assessment
- Evidence-constrained generation
- Marketplace thinking
How it was built · I use AI-assisted development to work directly in the implementation layer, while owning the product decisions, architecture, evaluation criteria and production validation.
Recruiting effort rarely compounds.
Recruiting effort rarely compounds. Candidates, relationships and past searches scatter across ATS systems, LinkedIn, spreadsheets and inboxes, so each role starts over — and the tools meant to help mostly match on keywords, which never proved the experience behind them.
Seven discoveries, one direction.
- 01
Initial Observation
What I saw
Both sides of the hiring market were working harder than ever and still missing each other — recruiters sending outreach for roles far from a candidate’s experience, while qualified people applied hundreds of times without being seen.
What it led to
That mismatch is what pulled me in. If effort this high on both sides still ended in misses, the problem probably wasn’t effort. It was something in how recruiting itself works.
- 02
Research
What I saw
Digging into ATS platforms, sourcing workflows, and recruiter behavior, one pattern kept surfacing: recruiters repeatedly rebuild value they already created. Candidates, relationships, and recruiting effort get trapped across ATS systems, LinkedIn, spreadsheets, inboxes, and personal files.
What it led to
Recruiting effort almost never compounds. Each role tends to start over, and the work from the last search rarely carries into the next. The bottleneck wasn’t technology — it was value leaking out of the system between roles.
- 03
Workflow Discovery
What I saw
Evaluating candidates, I was constantly moving back and forth between the job description and the resume, holding both in my head. The friction wasn’t the decision — it was all the context-switching around it.
What it led to
That realization came before any feature. Once the problem was friction, the design followed: structured review that keeps the requirements and the evidence in one place, so the recruiter isn’t reassembling context on every candidate.
- 04
AI Trust Discovery
What I saw
I kept hitting the limits of keywords: a resume might list Agile, Scrum, or product management, but the words being present never proved the experience behind them. The real question was always “what evidence supports this?” — and no recruiter should have to reconstruct that by hand, candidate after candidate.
What it led to
So evidence had to travel with the recommendation. Matching became requirement-level reasoning — the support for a fit attached directly to each requirement, judged on demonstrated experience rather than keyword presence — so recruiters can make fast, confident decisions without constant re-checking.
- 05
Recruiting Nuance Discovery
What I saw
Most recruiting products seem to assume fit can be fully determined through matching, search, or a score. But the hard hiring decisions rarely work that way — they turn on trajectory, adjacent experience, transferable skills, hiring-manager context, and recruiter judgment.
What it led to
So the goal was never to automate judgment. It was to clear the obvious matches and obvious misses, and route everything in between to Review — where a recruiter’s expertise actually adds value.
- 06
Marketplace Discovery
What I saw
Almost all the recruiting technology I looked at was built to help recruiters search ever-larger pools of passive candidates. Meanwhile the opposite problem was playing out in plain view: large numbers of active job seekers, searching hard, and still invisible.
What it led to
It left me with a question, not a conclusion: are we solving the wrong problem? If qualified people who are actively searching still can’t get seen, maybe the gap isn’t sourcing at all. Maybe it’s visibility and signal.
- 07
Network Discovery
The turning pointWhat I saw
Research consistently showed the same thing: recruiters rebuilding searches, rediscovering candidates they’d already found, and losing relationships scattered across systems. Matching was useful — but it was never the durable value. The durable value was the network itself.
What it led to
This was the moment the product thesis changed. Ryger stopped being a better way to match and became a way to own and grow a talent network — recruiter landing pages, owned candidate pools, and continuous accumulation — with matching repositioned as activation rather than the product.
“The matching engine wasn’t the asset. The network was.”
That reframe moved Ryger’s center of gravity from a single transaction to a compounding asset. Instead of helping a recruiter fill one role, it helps them build a talent network that gets more valuable with every search.
Growth — how the network compounds
A recruiter-owned network is only as valuable as its ability to grow. If recruiters have to manually source every candidate forever, the asset stays small. So recruiter landing pages and public candidate intake became core — a way to continuously grow the pool while the recruiter keeps ownership of every relationship.
Integrity — growth without losing signal
Public intake raised an obvious risk: recruiting is increasingly flooded with automated and mass-apply submissions, and a recruiter-owned network only works if recruiters trust the pool. Intake is protected by a honeypot, bot detection, per-role rate limits, file checks, a model gate that confirms an upload is actually a resume, and duplicate-person resolution.
The tradeoffs I made on purpose.
Review, not a forced yes or no
Every requirement resolves to Met, Review or Missed. Partial or unclear evidence goes to Review rather than being rounded to a verdict the evidence can’t support.
Keywords never prove experience
A keyword-only match is never elevated to Met, and a tool listed on a resume without supporting work history counts as Missed.
One place decides
Deterministic signals, model judgments and explanation text are kept separate, and a requirement’s status is assigned in exactly one function — so behavior is auditable and changes can be proven not to regress it.
The verdict can only be lowered
The model’s overall assessment is capped downward by deterministic rules: when more than three-quarters of must-haves are missing it cannot read better than “Stretch,” and an explicit work-authorization conflict forces “Unlikely.”
Requirement-level assessment, evidence attached.
How a job description and a candidate become a verdict a recruiter can check — every stage either deterministic or constrained to evidence that exists.
- 01
Structure
A job description becomes typed requirements — must, should or nice to have; gating or not; minimum years; any-of or all-of — with role duties kept separate and an instruction not to invent qualifications the text doesn’t state.
- 02
Retrieve
Candidates are embedded and retrieved by vector search across the recruiter’s own pools and the wider network, using separate queries for must-haves, tools and domain.
- 03
Rank
Deterministic, weighted scoring over exact, partial and related matches produces a fit score and band; semantic similarity adds credit only where there is structured evidence behind it.
- 04
Assess
Tools and tenure are checked deterministically first. The remaining requirements are assessed by a model in parallel batches, and every verdict must cite evidence IDs that actually exist in the candidate’s evidence pack.
- 05
Resolve
One function assigns Met, Review or Missed per requirement; the overall assessment is then capped by rules.
Evidence-constrained resume generation
Resumes are built for a single role, so experience that doesn’t match the current application quietly gets cut. Most tools make it worse — optimizing for keywords, or inventing accomplishments that no longer sound like the person.
Ryger’s resume generator reads a job description against the candidate’s whole career and surfaces the most relevant real experience first — under rules that keep it truthful.
Evidence is the only input about the candidate
The model receives extracted evidence rows, each tied to exactly one role, with verbatim quotes. The job description is explicitly not evidence about the candidate, and a stated goal is not an achieved result.
Checks in code, not in the prompt
After generation, every bullet must cite evidence from the same role, and every number and year must appear in that evidence. Lines that fail are removed, not repaired by the model.
Ungrounded skills are stripped
A grounding guard removes skills and certifications that don’t appear in the source material.
A limit stated, not hidden
The checks are objective — citations, numbers, dates, employer names — so a characterization borrowed from the job description can still slip through. That gap is measured and logged.
For technical readers · Architecture & stack
The stack supports the product decisions above; it isn't the story.
- Frontend
- Next.jsTypeScriptTailwindVercel
- Platform
- AWS LambdaAPI GatewayDynamoDBS3ECSCloudFrontSES
- AI & retrieval
- OpenAI modelstext-embedding-3-smallPinecone vector searchSchema-validated requirement extractionEvidence-cited requirement assessment
- Identity & billing
- ClerkStripe
- Integrations
- Google Maps APIGeocodingLocation proximity
- Key systems
- Recruiter-owned talent poolsCandidate ingestion pipelinesRecruiter landing pagesMatch and fit reasoningEvidence-constrained resume generationPublic-intake abuse controls
Truthfulness, checked in code.
Rules under test
The overall-assessment caps are covered by automated tests, and an input-equivalence harness checks that migrations preserve behavior.
Live, on both sides of the market.
Ryger is live at ryger.app, with recruiter and candidate workflows.
- Recruiter landing pages with public candidate intake
- Recruiter-owned candidate pools and a network for active job seekers
- Requirement-level fit with evidence, per candidate
- Shareable candidate slates
- Authentication and billing
The biggest lesson from Ryger is that technology alone rarely solves workflow problems. The most valuable opportunities show up somewhere quieter — in how people actually work, where trust breaks down, where information gets lost, and where systems fail to compound value over time.
What I’d measure next.
The product works in production today. These are the next layers of measurement and rigor I’d add as it matures.
- 01Build a human-labeled ground-truth set of candidate–requirement pairs, so Met / Review / Missed accuracy is measured directly. Today’s relevance labels are model-authored.
- 02Extend the resume checks beyond objective facts, to catch characterizations borrowed from the job description.
