RocketJob: an AI job-search platform and application service
A resume-tailoring engine with versioning and pixel-faithful PDF output, a content platform built for search, and a human-in-the-loop application service, engineered by Vision Nexera for RocketJob.
Context
RocketJob is an AI-powered job-search platform paired with a done-for-you application service. Vision Nexera designed and built the platform end-to-end for the RocketJob team: candidates get resumes tailored per job (the service commitment is up to 40 tailored applications per week per client, with interview preparation) while the platform automates the engineering underneath.
The problem
Tailoring a resume properly for every application is the single highest-leverage, least-done task in a job search, because doing it manually takes 30–60 minutes per role. The engineering problem: make AI tailoring trustworthy enough to send, which means version control, human review, and a PDF that renders exactly as previewed.
Constraints that shaped the build
- Output goes to real employers, so 'mostly right' is not shippable: every tailored version is reviewable, diffable, and reversible.
- PDF fidelity is non-negotiable: the preview a candidate approves must be pixel-faithful to the file an employer opens.
- The public content platform had to earn search traffic, so schema, performance, and analytics were built in, not bolted on.
- AI assists; humans stay in the loop on everything that leaves the building.
Architecture
The system, drawn honestly
Job intake is not a scrape-and-hope: postings are fetched from URL or paste, deduplicated by content hash, and structured (company, role, location, seniority, must-haves, nice-to-haves) before a single token of tailoring runs. Requirement extraction is a separate step from tailoring, so the same job can be re-tailored later against a corrected requirement list without re-parsing the posting.
The tailoring engine treats a resume like source code: every AI rewrite is a version with a diff against the base, stored so a reviewer sees exactly what changed and why before anything ships. Immediately after tailoring, the output runs an ATS-parseability check (a headless parser reads the generated resume the way an employer's ATS will) and any regression in machine-readability (dropped section headers, mis-detected experience blocks) blocks the send. The PDF renderer then guarantees two-way parity: the preview a candidate approves matches the file an employer opens, both visually and when re-parsed.
Delivery is a channel adapter, not a single script: some jobs get an email with attachment, some a portal submission with structured fields, some a referral. The adapter records the channel used, the timestamp, and the deliverability signal (accepted, bounced, waiting). Outcomes (reply, screen, interview, offer) are captured per application and, once labelled at scale, feed back into the requirement-extraction and tailoring stages as evaluation fixtures. That loop is what makes the 40-per-week service commitment operable by a small team instead of an army of writers.
Build notes
Decisions worth stealing
- Resume versioning is modelled explicitly: base resume plus per-application diff plus rendered artefact, all persisted. Diffable revisions turn AI output from a liability into a reviewable artefact you can roll back.
- The ATS-parseability check is the unglamorous feature that earned trust: any tailoring change that would make the resume harder for a downstream ATS to parse fails review, not the candidate's application.
- PDF parity is enforced with a golden-file test: the produced PDF is re-rendered and re-parsed on every engine change, and a text-level diff against the approved preview blocks the release if it drifts.
- The delivery layer is a channel adapter with retries, deliverability tracking, and dead-letter handling: email bounces, portal errors, and rate limits are surfaced to the operator, not silently swallowed.
- The blog and content system runs on Next.js with MongoDB/GridFS-backed media and a Tiptap editorial pipeline, built search-first with schema and analytics wired to publishing decisions.
- An in-portal bug reporter shortened the feedback loop from users to fixes. Small feature, outsized operational value.
- GA4 instrumentation across the acquisition and application funnels means content and product decisions argue with data, not opinions.
- What we would do differently: model requirement extraction as its own versioned artefact from day one. We merged it with tailoring early, and paid to unpick it when the eval loop needed to score the two stages separately.
Results
What we measure
- Tailoring turnaround time per application vs the manual baseline
- Interview-invitation rate for tailored vs untailored applications
- Organic search impressions and clicks to the content platform
- Weekly applications delivered per client against the 40/week service spec
The 40 applications per week figure above is the service specification (what RocketJob's customers buy) not a performance claim. Measured performance figures belong to RocketJob; anything published here will carry their sign-off, a source, and a date.