A job-search platform that screens career boards, honestly scores fit against a real master resume, tailors a resume and cover letter per posting, and tracks the pipeline through to outcome - built to make my own job search more direct, not a demo. I've used it myself, while searching for that next role.
A job-search platform that screens career boards, honestly scores fit against a real master resume, tailors a resume and cover letter per posting, and tracks the pipeline through to outcome. This automates the discipline - search, scoring, drafting, and pipeline tracking - without automating away the judgment: the AI screens, scores, and drafts; the person still decides what's true, what's good enough, and when to hit send.
The workflow, one deliberate click at a time - nothing advances on its own:
agentkit, ported from Tourney): company discovery, fit scoring against a real master resume, resume and cover-letter tailoring that only rephrases real experience, and a pipeline tracker from apply to outcome - with a frontier-model worker and a self-hosted worker on identical plumbing.The AI mechanics are a generalized, portable package (agentkit) - a queued, tool-using model loop that any app can lift by copying one folder. It's a direct port of the job-queue pattern already hardened in Tourney, and the worker side imports AI Worker Boundary directly - the same shared worker-trust rules every app on this platform runs under.
The model can propose. It can never silently act.
Nothing selected yet — click a box above.
claude -p in a subprocess, non-interactive - one prompt in, one result out, no terminal session to babysit. Billed against an existing subscription rather than the API, at roughly a 10-20% discount on token cost.Two independent checks gate every tool call: the worker's claimed identity, and whether that tool is even registered for that job's type. A worker that lies about which tools it wants gains nothing - an unregistered tool name is refused outright.
Researching the competitive landscape surfaced a clear pattern: the worst-reviewed tools in this category are exactly the ones that auto-submit applications on a user's behalf.
Past the working tool, there's a real product plan behind it: a three-tier AI serving model (bring-your-own Claude access at zero marginal cost, a self-hosted tier on owned hardware, and a platform-paid tier for convenience), priced against researched competitors (Teal, Jobscan, Simplify.jobs, LazyApply, Sonara), with the honest no-auto-submit design as the actual competitive edge - not a missing feature, the reason the worst players in the category get the worst reviews.
Everything above covers what GetSeen is. From here on is how it actually works - the real architecture, the resume-tailoring pipeline, a real cross-tenant data-leak bug found in a security sweep and fixed comprehensively, a live production tradeoff, and the tests that guard all of it. Sourced directly from GetSeen's own commit history and code, not written from memory.
GetSeen's dashboard runs on Python's own built-in web server (http.server) rather than a third-party framework like Flask or Django - a deliberate choice, not a shortcut. Routing and request handling are written by hand instead of relied on from someone else's package, which means no framework version to track, no framework vulnerability to patch, and nothing running that isn't code Derek wrote or Python itself ships with. That tradeoff - more boilerplate, in exchange for zero external dependencies - made sense for a tool that started as a single-user project and grew to support multiple separate users, never a large enough surface to need a full framework's routing, templating, and middleware machinery. The queue that hands work off to AI reuses the same proven design already running in Tourney: safe hand-off of one job to one worker at a time, a record that a job only gets marked "done" once, and jobs that go stale get automatically cleared - the same rules, the same tested logic, not reinvented from scratch.
Two separate queued AI engines can do the same job through identical plumbing: one runs through Claude Code, Anthropic's own coding assistant, billed against an existing subscription; the other runs the same job through a self-hosted, open-source model on FOMX.ai's DGX Spark instead, for free. Only which "brain" does the thinking changes - everything else about how the job runs stays the same. A third path, Claude's own metered API, is wired in separately and opt-in only, used to double-check an answer rather than to run the queue - it's billed per call, unlike either queued worker, which is why it's kept out of the queue entirely.
Drafting a tailored resume and cover letter is the one step in this whole system that actually requires judgment - it's the reason the AI job queue exists at all. Whichever AI engine handles a job, it's given one absolute rule, enforced in its instructions every time: it may only reword, select, and reorder experience that's already documented in the master resume. It's never allowed to invent an employer, job title, date, skill, or accomplishment, and every paid role has to appear, in the right order, never left out.
The finished resume is generated as a Word document built specifically to pass through automated resume-screening software (the "ATS" systems most companies use to filter applicants) - a single-column layout, no tables or images that confuse a parser, and section headings written the way those systems expect to read them, all while still looking like a real, professionally formatted resume to a human reader.
Every job the system tracks now records which user it belongs to, on top of its type and status - a fix made permanent after the incident described in §11. Each user's data lives in its own separate workspace, so two people (or two customers, in a future multi-user version) can run the same system side by side without ever seeing each other's information. That separation was a deliberate design choice, so the same codebase can serve one person today or many people later.
GetSeen's production environment is deliberately closed to real traffic - an active decision, not an oversight. More time is wanted testing it in the pre-production environment first. Rather than leave a half-ready build reachable at its live production address, that address just shows a simple, honest "still being tested" page. The pre-production testing environment itself is completely unaffected and keeps running normally. Turning production back on later is a small configuration change and a redeploy - no code changes required.
A security review on 2026-09-18 found that while most of the system already kept each user's data properly separated, a few shared, lower-level components didn't. The most serious finding: one user could potentially view another user's job - including the actual text of their resume - simply by guessing or trying different job ID numbers, because the underlying job queue had no concept of who a job belonged to.
One exception was kept, deliberately: the AI worker itself still needs to see every pending job across all users, because it runs on one shared piece of hardware serving everyone. That's a documented, intentional exception - not a gap that was missed.
Test coverage here is honest rather than padded for appearances: three focused test files, all recent, all written to verify real fixes rather than to pad a coverage number - two of them came directly out of the data-privacy fix in §11, and a third specifically covers the bulk-action usage limit described there. All 20 of those tests passed, and the automated code-quality and security scans came back clean. Every change still goes through the same five-step automated review pipeline used across the whole platform (see Engineering Platform), even though this particular test suite is still young and will keep growing.