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.
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.
What it demonstrates for client work
The useful work lives between a person’s messy reality and a system’s technical limits. JobPilot demonstrates that motion: translate the workflow, integrate 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.