Account-based job searching: one record per company, carrying 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 automatically against the right application.
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 goneEvery 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.
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.
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.
Colleagues comment inline, the way a design review works. Accepted comments become the next version, and every version is kept.
In the product this ships as Deep Tailor, and the four passes are named for the job each one 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, and 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.
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.
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.
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.
Running this many agents in production needed governance, so I built the control plane by hand: every system prompt in one place, and per prompt the tools it may call and the MCP servers it may reach. Changing agent behaviour 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.
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.
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.
SupabaseAuth and the application records.
PrismaSchema and migrations.
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.
Nine systems shipped, compliance, reporting, intelligence, content.
