Why not just add semantic search to a normal job board?

A search box still makes the candidate do the work repeatedly. Inverting it — saving intent and pushing new matches as postings arrive — turns a passive board into an active recruiter, which is the actual value. Semantic matching is a piece of that, not the whole thing.

How do you keep an LLM-matching feature affordable at scale?

Structured pre-filters shrink the candidate set before any model runs, embeddings handle semantic similarity cheaply, results are cached so nothing is recomputed, and token budgets cap spend. The model is used only where fuzzy intent genuinely needs it.

What does Ali Asghar specialize in?

Senior full-stack (MERN) engineering and technical leadership — multi-tenant SaaS architecture, production payment systems, and AI-assisted delivery, primarily in React, Next.js, Node.js, NestJS, and PostgreSQL.

Is Ali available for hire or remote work?

Yes — open to select senior software engineering and technical-lead roles, remote-first from Lahore, Pakistan. The fastest way to reach him is WhatsApp or email, both linked in the contact section.

What is Ali's tech stack?

Frontend: React, Next.js, TypeScript, Tailwind. Backend: Node.js, NestJS, PostgreSQL, Redis, BullMQ. Cloud & DevOps: AWS, OVHcloud, Docker, GitHub Actions CI/CD. Plus Stripe, GA4/Measurement Protocol, and agentic AI tooling.

What kind of products has Ali built?

Production SaaS with real stakes: multi-tenant WPS-compliant payroll (Paylio), a payment-analytics dashboard over live PSP webhooks, multi-currency European commerce, and an automated print-on-demand render pipeline.

How does Ali work with clients and teams?

As a technical lead: he scopes the smallest valuable slice, owns the architecture and code review, leads a five-person team across a nine-product portfolio, and measures engineering in business outcomes — not just features shipped.

Building an AI recruiter: matching that runs toward the candidate, not a search box on top of listings

A keyword job board makes candidates do the searching, over and over, and never understands what anyone actually wants. On RadiologyJobs I built the matching to run the other way: an AI recruiter layer sits in front of the listings, scans new postings as they arrive, and pushes matches to the candidates already looking — with an employer side built for bulk hiring, not one form per role.

The real problem is intent, not keywords

"Locum neuroradiology, weekends only, near Chicago, over 80k" is a sentence a keyword filter mangles. The candidate knows exactly what they want; the board forces them to translate it into checkboxes and then re-run it every day. The product problem is capturing intent once, in plain language, and honoring it continuously.

Invert the flow: push, don't poll

So the matching runs toward the candidate. A candidate expresses intent in plain English; that intent is saved. As new postings arrive, they're scanned and matched against every saved search, and matches are emailed directly. The candidate stops searching; the system does the work in the background.

An AI layer in front of the listings

This is a layer, not a search box bolted on. Plain-English intent is parsed into structured criteria, postings are enriched on ingest, and matching combines structured filters with semantic similarity so 'weekend locum neuro' finds the right roles even when the posting doesn't use those exact words. The listings database stays the source of truth; the AI is the matching brain in front of it.

The design principle: use AI where fuzzy human intent meets structured data. Parsing 'what I actually want' into criteria, and matching it semantically against enriched postings, is exactly that seam.

Cost and reliability, because it's a real product

Scanning every posting against every saved search with an LLM naively would be slow and expensive. So structured pre-filters cut the candidate set first, embeddings handle semantic similarity cheaply, and the model is reserved for the parts that genuinely need it — with caching so the same posting isn't re-embedded and token budgets kept in check. AI earns its place per unit of value, not as a blanket call on everything.

The employer side: built for volume

Employers don't want to post one form per role. The dashboard is built for bulk hiring: XML/CSV import to bring roles in at scale, and team workspaces so a hiring group works together. The candidate experience is 'plain English and let it come to me'; the employer experience is 'load everything and manage it as a team.'

Key takeaways

Capture intent once in plain language; don't make users re-search forever.
Invert the flow — scan new supply against saved demand and push matches.
Put AI at the seam where fuzzy intent meets structured data.
Pre-filter and embed cheaply; reserve the model for what needs it, and cache.
Match the interface to the user: plain-English for candidates, bulk tools for employers.