Job Research
AI job-search product at a startup · 2025 to 2026
A conversational job-search assistant for frontline workers, the people who stock warehouses, run registers and care for patients. I was the technical lead of that app, and I built the pipeline that filled its jobs database alone.
- The problem
- Frontline workers job-hunt with tools built for corporate profiles.
- What I did
- I led the app and built its data pipeline alone.
- The result
- A product that finds the jobs that fit your profile and helps you grow.
Frontline workers search for jobs with tools built for someone else
The people who stock warehouses, run registers and care for patients look for work with tools designed for corporate profiles: keyword filters, resumes, dashboards. We set out to give them a conversation instead. Ask a plain question and one screen answers it: an AI summary, real listings pulled from live search, the sources it used, and what to ask next.
I led the app, and I built the engine behind it alone
I led the research app as its technical lead, from its first commit onward. I also built the second app behind it, the ingestion pipeline that kept the jobs database full, essentially alone. The AI was the product's core feature, while the code itself was still typed out by hand with an AI assistant for support.
A deep research flow that returns matching jobs.
Someone types a question about their career. One model step decides whether it is a jobs question at all and rewrites it into a self-contained query using the conversation so far. Then the app searches in parallel across the sources the person ticked: the open web, live job listings, and video. The three results merge into one answer written against the professional profile parsed from their uploaded resume, with the jobs that fit it and concrete next steps to get them.
I built the pipeline from raw listing to page.
The assistant is only as good as the jobs behind it, and those came from a pipeline I built alone. It pulled listings in from several feeds, enriched each company, used AI to normalize titles, pay and location into one consistent shape, and gave every listing its own clean address on the site so search engines could index it. Each stage ran as its own background job, in batches, so one bad row never took the whole run down with it.
Fast models for search steps, strong ones for answers.
The research flow runs as several steps, each with its own task and its own declared output shape. Each one ran on a model chosen for how fast it had to answer, because a person who waits too long gives up. Steps that only build a search query or condense results ran on a fast model, and the ones that reason and write the final answer ran on a stronger one. One step also had a hard limit on its input text.
Two apps, one product, and the patterns I still use
I shipped two apps that made one product. The research app answered in natural language and put an AI summary, real listings, their sources and the next questions to ask on one screen. The pipeline behind it filled the jobs and companies database, normalized every listing, and gave each one its own public page. Those pages were what search engines could index.
I can engineer a language model into a product feature: every step with its own prompt, an output shape the app declares and validates, and the model that step actually needs, instead of one long prompt.