Career Capybara runs a job search the way a GTM team runs accounts
I built this for my own search and I am its only user. Stripe is live on it, and nobody has bought a plan.
Account-based job searching, with one record per company. That record holds the tracked stage, the company research, the tailored resume, interview prep with voice, and every email exchange filed against the right application. An agent team writes that resume for the ATS and for the two humans who read it.
A job search is a pipeline, and everyone runs it out of a spreadsheet
Every application is an account: it has a stage, a set of documents, research on the company, and several humans you are in conversation with. That is the shape B2B sales solved twenty years ago with a CRM, and job seekers still run it across a spreadsheet, a Drive folder and an inbox.
The cost lands in two places. Manual work eats the hours that should go into preparation, and the human side decays: a recruiter emails on Tuesday, the reply goes out Friday, and by then the thread is cold. Meanwhile the applicant's own record of what was said, to whom, and what comes next lives in their head.
So I built it the way I would build a GTM system: account-based, one record per target, with the manual work automated and the human contact protected.
Company, role, date applied, stage. Accurate for about two weeks, then only as accurate as the last time anyone touched it.
manual upkeepExported as its own PDF with its own filename, sitting in a downloads folder rather than against the job it was written for.
one file per attemptGeneric questions for the job title, with no knowledge of the posting, the company, or the version of you that was actually sent.
no shared contextWhich PDF went where, which claims you made, and what you promised to follow up on.
the record is goneSpreadsheet trackers, chat tabs, Jobright
Every job seeker runs some version of this stack, and I ran it too before deciding it was the problem.
Complete control, no cost, and a shape everyone understands.
It holds a stage and nothing else, and only for as long as somebody keeps updating it. The resume, the research and the prep live somewhere else.
RejectedA competent rewrite of any bullet, in seconds, for a subscription most people already pay.
The tab forgets the role the moment it closes, and one pass produces the document a hiring manager has read a hundred times this month.
RejectedAutomated discovery and a match score against each posting.
When six candidates all score in the mid-nineties on the same role, the score has stopped separating anybody.
RejectedNone of the three is bad at its own job. The gap is between them: no object holds the posting, the document that was sent, and the preparation for the conversation.
One application has to satisfy three different readers
This is the product decision everything else follows from. An application is read by an ATS, then by a recruiter, then by a hiring manager, and the three want different things from the same document.
The ATS wants parseable structure and matching terms. The recruiter scans in seconds and wants the relevant facts where their eye lands first, which sometimes means the bullets should be reordered for this specific role. The hiring manager wants evidence of real capability and can smell a generated claim from the first line.
Optimizing for one of them breaks the other two, so the tailoring engine is built to hold all three at once.
A resume nobody can generate in one pass
Every AI resume tool now produces a perfect-looking document, which is exactly why a perfect-looking document stopped being worth anything. If the output could have been generated from the job description alone, it says nothing about the candidate.
So the engine never writes a resume in one call. It decomposes the document, works section by section against the real history, and passes each one through an agent team that challenges its own draft and revises it before anything reaches the page.
Each experience block is written from what happened in that role, so the claims stay defensible in the interview that follows.
One pass optimizes for a recruiter scanning in seconds, including bullet order. A second reads as the hiring manager and cuts anything that sounds like filler.
Agents review every draft before it becomes output, the same shape as the content systems I build at work.
You comment inline on the document the way you would in a design review, accepted comments become the next version, and every version stays.
In the product this ships as Deep Tailor. Each pass is named for the job it does. Read the room takes the posting apart into what the role owns. Find the substance locates the candidate's real work in the terms this role cares about. Rewrite the lines re-tells every experience for it. Read it back goes through the finished document the way a senior recruiter would. Four passes exist because one pass clears the ATS filter and stops there, leaving the recruiter and the hiring manager the same document to read.
I automate the manual work here to protect the human contact
Borrowed straight from Salesloft: every exchange with a company belongs on the record. A Gmail integration watches for those threads and files each one against the right application, so the history is there when you need to answer quickly.
Interview prep is generated per application from the industry, the job description and the interviewer, with voice so you can rehearse it out loud. A career-coach knowledge base sits underneath, built from the shared advice of more than a dozen recruiters, so the guidance at each stage traces back to that recruiter advice.
The record does not stop at the offer. The same workspace carries the first 30, 60 and 90 days, because that is when the job is actually won.
Every card on the board carries the document that was sent with it
Draft, applied, screening, interviewing. A posting becomes a tracked application in one action, and the stage is the single source of truth.
Company intelligence, the job spec, the tailored resume, salary context, prep and recordings, all against one account.
One master document, a tailored variant per application, ATS read-out on each, and every version kept.
You pick the template and set the type down to the line height, then export the PDF. The only parser check behind it is the built-in ATS read-out.
The resume stays attached to the job it was written for
A spreadsheet, a resume builder and a prep tool do not talk to each other. Dozens of applications in, you are guessing which PDF went where, and the guess is usually wrong in the one case that mattered. Making the application the record instead of the row fixes that in a single stroke.
Four steps hang off that one object. Save the job with its spec, research, salary band, stage and next step. Deep-tailor the resume against it, attached to the role rather than filed loose. Apply through the Chrome extension, which fills supported forms with the right document. Then prep from the same record: questions generated off this posting, a live mock, and a recorded answer to watch back.
Five places in the product read the same record: the tracker, Deep Tailor, interview prep, the autofill extension and the career tools for planning, negotiation and coach chat. Tiers and a credit meter exist because the model calls cost me real money. I never train on user documents, and I put that in writing on the product page.
The parts I had to build before the product could exist
I built the control plane by hand to govern this many agents in production. Thirty-five system prompts sit in one console, grouped by job, each pinned to a model with its usage count and its required capabilities. Each prompt also declares the tools it may call and the MCP servers it may reach. I adjust agent behavior in the config, and the audit trail keeps the prompt diff and the timestamp. There is no eval suite behind it.
Alongside it sit a CMS for onboarding content and an assistant wired to three knowledge bases: the career-coach corpus, the product documentation, and the user's own applications. Asking it where something stands returns an answer from the record instead of a guess.
Let me be straight about what this is. It has not been sold and I am not going to dress a side project up as traction. What is worth showing is the build: one control plane, three knowledge bases, four-model routing and thirty-five system prompts, governed and audited. I would do the same work on a GTM system, turning a pipeline into a trackable object and running an agent team in production.
The deepest build in the set, and the only one with its own agent control plane
Four models is a routing decision. Gemini 2.0 Flash runs most of the thirty-five system prompts, Gemini 2.5 Pro takes the heavier tailoring and review passes, DeepSeek carries the high-volume passes on the cost tier, and GPT-4o holds the deciding seat for the cases where the other two disagreed in testing. Each prompt in the console names the model it runs on and the capabilities it needs. I move a prompt to another tier by editing that config, and the change gets logged.
Application
React 19The board, the resume workspace, the record view and the prep tools.
TypeScriptAcross the app and the agent contracts.
ViteBuild tooling.
Express 5The API layer behind the agents.
Chrome extensionAutofill on supported application pages.
Models
Gemini 2.0 FlashThe default for most of the thirty-five system prompts, pinned per prompt in the console.
Gemini 2.5 ProThe heavier tailoring and review passes.
DeepSeekCost-tier routing for the high-volume passes.
GPT-4oUsed where the other two disagreed in testing.
Data
SupabaseAuth and the application records.
PrismaSchema and migrations.
Delivery
ResendStage-change and interview reminders.
StripeFree, Pro and Elite tiers with a credit meter. Nobody has paid for one yet.
VercelHosting.
Want this kind of tooling on your team?
I turned a job search into a tracked pipeline and put thirty-five prompts behind one control plane.