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. It has not been sold.
Account-based job searching, with one record per company. That record carries the tracked stage, the company research, a resume tailored by an agent team for the ATS and the two humans who read it, interview prep with voice, and every email exchange filed against the right application.
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 exactly 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 already 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 already 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, which is where the whole product idea came from.
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 has about ten 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 drafts, challenges and revises before anything reaches the page.
Each experience block is written from what actually happened in that role, so the claims stay defensible in the interview that follows.
One pass optimizes for the recruiter's ten seconds, including bullet order. A second reads as the hiring manager and cuts anything that sounds like filler.
Layered agent review sits between draft and output, the same shape as the content systems I build at work.
The document model supports inline comments the way a design review works, with accepted comments becoming the next version and every version kept. I am the only person who has used it.
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 actually 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 produces a document that clears the filter and stops there, which is the first gate and not the finish line.
Automation exists 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 it can be rehearsed out loud rather than read. A career-coach knowledge base sits underneath, built from the shared advice of more than a dozen recruiters, so the guidance at each stage comes from the market rather than from a model's opinion.
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 rather than overwritten.
Template, typography and spacing controls, then a PDF that survives the parser it is about to meet.
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. By application forty 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 surfaces sit on 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 real money, and user documents are not used as training data, which the product states on the page rather than burying in a policy.
The parts I had to build before the product could exist
Running this many agents in production needed governance, so I built the control plane by hand. Every system prompt sits in one place, and each one declares the tools it may call and the MCP servers it may reach. Changing agent behavior is a config change with an audit trail rather than an edit buried in code.
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.
To be straight about what this is: I built it for my own search and I am its main user. It has not been sold and I am not going to dress a side project up as traction. What it is worth showing for is the build itself, which is the deepest one here and the clearest picture of how I think about product rather than campaigns.
The deepest build in the set, and the only one with its own agent control plane
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.
VercelHosting.
Four models is a routing decision. Each prompt in the console names the model it runs on and the capabilities it needs, so changing the tier is a config edit with an audit trail.
Want this kind of tooling on your team?
Nine systems shipped, compliance, reporting, intelligence, content.