CVSummit

Resume optimisation sounds like a language-model problem and mostly is not. The model is perfectly capable of improving a bullet point once it can see one. Getting to that point is the work: a resume arrives as a PDF or a DOCX laid out in two columns, or a table, or a template that renders beautifully and stores its text in an order no human would read it in.

So the first component built was not the analysis engine. It was extraction - recovering reading order, identifying section boundaries, and separating a job title from the company from the dates when all three sit on one line with inconsistent separators. Everything downstream depends on it, and an extraction error produces a confidently wrong score rather than an obvious failure.

A user who runs the same resume twice and receives two different scores stops trusting the product immediately, and the trust does not come back. That is a harder constraint than it sounds, because language models are not deterministic by default.

The resolution was to separate the two kinds of judgement. Anything checkable by rule - keyword coverage against the target role, section presence, date continuity, formatting that breaks automated parsers - is computed in code and produces the same answer every time. The model is used where judgement genuinely is required: phrasing, tone, whether a bullet describes an achievement or a duty. Scores come from the deterministic layer; the model supplies the suggestions.

This split also made the product cheaper to run. Most of what a user sees on first analysis costs nothing in inference, which matters when the pricing has to survive users who analyse a resume fifteen times in an evening.

Applicant Tracking Systems are not one system. They are dozens of products of different vintages, and they disagree about what they can parse. A layout that one handles cleanly, another flattens into unusable text.

We deliberately avoided claiming compatibility with named systems, because that claim ages badly and cannot be verified from outside. What the checker does instead is test for the failure modes that are common across parsers - text inside images or text boxes, multi-column layouts, tables used for structure, non-standard section headings, glyphs that survive rendering but not extraction. A resume that avoids all of those parses correctly nearly everywhere.

The product promises analysis in under a minute, and that number shaped the architecture more than any other requirement. A naive implementation - extract, then one large model call per section, sequentially - comfortably exceeds it on a long resume.

The work runs concurrently on FastAPI instead, with the deterministic checks executing while model calls are in flight, and results streamed to the interface as each section completes rather than held until everything finishes. A user watching sections resolve one by one perceives the tool as fast; the same total duration behind a spinner reads as broken. Redis caches extraction output, so re-running an analysis after a small edit does not repeat the expensive parsing step.

Building for the Saudi market means Arabic and English resumes, frequently mixed within one document - an Arabic name and address above English job titles and technology names. This is not a translation feature that can be added later; it changes text extraction, reading direction, and every layout assumption in the templates.

Retrofitting right-to-left support into an interface designed left-to-right is substantially more expensive than accommodating it from the first commit, which is why it was treated as a constraint rather than a roadmap item.

The extraction layer is where we would spend more time given the project again. It is the component that determines the quality ceiling of everything above it, and it is the one where an incremental improvement is felt across every feature simultaneously.