CASE STUDY · ENTERPRISE SOFTWARE · AI-POWERED HIRING

AI hiring platform engineering: the systems inside Jobvious

Jobvious is a US referral-based hiring platform where an AI engine matches candidates to roles and a referral network pays people for bringing others in. I've built at the core of business operations for Jobvious. This is what that engineering looks like.

The product: hiring that routes through people, ranked by meaning

Jobvious (itsjobvious.com) is built on two ideas that reinforce each other. First, a referral network: the best candidates usually arrive through someone who knows them, so the platform lets people earn by bringing others in, turning every user into a recruiting channel. Second, AI matching: once candidates are in the system, an engine matches them to roles by semantic similarity instead of keywords.

The second idea is the one that separates a hiring platform from a job board. Keyword search fails at hiring because resumes and job posts describe the same skill in different words. A candidate writes "built REST services in Node," a role asks for "backend API development," and a string match sees no overlap where a recruiter sees an obvious fit. Solving that, and everything around it, is the engineering surface I own in this story: the matching architecture, the referral attribution engine, the integration pipelines, and the application surfaces users actually touch.

Semantic matching: embeddings, vector search, and bi-directional scoring

Matching runs on semantic embeddings and vector search. Candidate profiles and job roles are embedded into high-dimensional vectors that encode meaning rather than exact wording, and those vectors live in Qdrant, a dedicated vector database. Finding candidates for a role (or roles for a candidate) becomes a nearest-neighbor search in vector space instead of a keyword query against text columns.

The scoring is deliberately bi-directional. A one-way search answers only half the question: a candidate can look similar to a role's description while the role is a poor match for what the candidate actually offers. Jobvious scores candidate-to-role and role-to-candidate, so both sides of the marketplace get rankings that reflect real fit. The relational source of truth stays in MySQL via Prisma; Qdrant holds the vector index the matching engine searches. Each store does the job it's built for.

The referral engine: attribution across the app-store gap

A referral network only works if attribution does. If someone shares a link and the person they referred signs up, the platform has to credit the right referrer, reliably enough that money can depend on it. On the web that's a solved problem; on mobile it isn't, because the trail breaks at the app store. A referral click happens in a browser, then the user installs a native app, and the install carries no memory of the click that caused it.

The Jobvious referral engine bridges that gap with device-fingerprint attribution: the click and the install are fingerprinted and linked, so a referral that starts as a tap on a shared link and ends as a fresh app install still resolves to the person who made it happen. That link is what makes "earn by bringing others in" an engineering fact rather than a marketing promise.

Integration pipelines: the platform behind the platform

A hiring platform doesn't exist in isolation. It has to move data in and out of the systems recruiting already runs on. The heaviest of these is a two-way sync with JobDiva, the ATS: jobs and candidate data flow in both directions, which means reconciling two systems that each believe they're the source of truth.

Around the sync sit the operational pipelines: resume parsing that turns uploaded documents into structured candidate data the matching engine can embed, background-check flows, and notification delivery. All of it runs on queue-backed workers over Redis: jobs are enqueued, processed asynchronously, and retried on failure, so a slow parse or a third-party hiccup degrades a queue's latency instead of a user's request. This is the unglamorous layer where hiring platforms actually live or die. Less the ranking algorithm than whether the data behind it stays correct while two external systems and a mobile user base all write to it at once.

One codebase, four surfaces

Jobvious ships to more surfaces than most platforms twice its size: a candidate app, an employer portal, an admin console, and real-time chat over WebSockets connecting the people on it. The candidate app runs on the web and as native iOS and Android apps via Capacitor, from one React and TypeScript codebase. One codebase means one implementation of every feature and one place for every fix, while still shipping through the app stores as a real native app. That's exactly what makes the referral engine's click-to-install attribution matter.

The platform's in-product support chat is powered by Lumo, an AI support assistant I built and sold to Jobvious, a separate story with its own case study.

What this proves

This is the pattern across everything Exybit builds: not one clever component, but a whole operating system for a business. An AI matching engine, a money-adjacent attribution system, external integrations that stay consistent, and native apps, all coherent inside one NestJS/TypeScript architecture. The engineering I've built at the core of business operations for Jobvious is the same class of work I do as Exybit, a custom software solutions practice in Cebu, Philippines: production systems that a real business runs on every day.