Work / Case study

JobPilot — ATS-first application copilot

JobPilot is the system I built for the job-search problem I was living: too many postings, too much repeated form work, and too much room for sloppy automation to make things worse. It finds company-owned ATS roles, scores fit, drafts tailored materials, tracks the queue, and keeps the final submission in human hands.

View source on GitHubAsk about JobPilot

Why I built it

The application process is a workflow problem before it is a motivation problem. A good role can hide in a noisy queue; a strong answer can turn into copy-paste sludge; a tailored resume can take long enough that the user stops applying altogether.

JobPilot turns that mess into a pipeline. It does the repetitive work a computer is good at, then stops where human judgment matters. That is the product point and the portfolio point: I can take an ambiguous, customer-facing workflow, find the real constraints, build the system, and say plainly where the boundary is.

What it does

  • SourceRead public Greenhouse, Lever, and Ashby boards so the job search starts at the company-owned application surface.
  • ScoreRank roles against a configurable policy, role-function fit, location gates, skill overlap, and work-style signals.
  • DraftGenerate resume and answer drafts from a verified account bank, with AI only as a rewrite layer when a backend is available.
  • TrackKeep queue, application history, status, and manual logs in local SQLite-backed state so duplicate work is visible.
  • ReviewProduce paste-ready artifacts for a normal browser session. JobPilot helps prepare the application; the human submits it.

How it’s built

The repo is a practical Python product, not a slide. It has install paths, CLI commands, tests, a local data model, browser integration, and docs for non-programmers and helpers.

  • CLIPython with Typer and Rich: profile setup, scan, score, resume, queue, log, doctor, and answer commands.
  • ATS readsPublic Greenhouse, Lever, and Ashby endpoints normalized into one queue model before scoring.
  • Browser layerPlaywright and Chrome DevTools Protocol where browser context is useful, with submission kept outside automated control.
  • EvidenceA true-accounts bank grounds application answers so drafts do not invent metrics, titles, customers, or experience.
  • Local stateSQLite and JSON files keep profile, queue, applications, policy, and work-style data on the user's machine.
  • AI routingOptional Gemini or local LLM support improves summary and answer wording; the non-AI path still works from templates.

Why it matters for Solutions Engineering

Solutions Engineering lives in the space between the customer’s messy reality and the product’s technical truth. JobPilot is my proof of that motion: translate the workflow, integrate the outside systems, build the useful tool, and keep the risk boundary clear.

  • Customer workflow senseThe product starts from the user's painful, repetitive workflow and turns it into a clear path: find, score, draft, track, submit.
  • Integration judgmentIt deals with real third-party systems and their limits instead of a toy API: ATS boards, browser sessions, local files, and user policy.
  • Human-in-loop designThe system draws a bright line around the risky step. Automation drafts; the person reviews and submits.
  • Field-tested pivotsAutomated live-form submission was rejected after ATS spam signals made the risk obvious. The product moved to paste-ready review artifacts.

What changed after real use

The early temptation was to make the browser do everything. That was the wrong product instinct for live application forms. ATS anti-spam systems can detect automated browsers, fresh profiles, repeated loads, and instant bulk fills. So the product moved to the reliable shape: source, score, draft, generate a paste sheet, then let the person submit from their normal browser.

That decision is the kind of engineering judgment I want visible. A useful system is not the one that automates the most; it is the one that gets the user to the outcome without creating a larger risk.

Truth boundaries

  • BoundaryNo paid users, revenue, or enterprise adoption claimed.
  • BoundaryNo auto-submit claim: JobPilot keeps the human responsible for the final application.
  • BoundarymacOS-first today; Windows and Linux are not promised as shipped.
  • BoundaryPersonal policy, profile, resume, queue, and application data stay local and are gitignored.

Where to look

Start with the README, then read the application-flow doc and the queue builder if you want the product judgment. The source is public and MIT licensed.

View source on GitHubRead the EYE case study