CV Tailor

Before CV Tailor there was a Google spreadsheet and a lot of copy-pasting. The spreadsheet recorded where I had applied, when, and what came back. The CV itself lived in Canva, in a design I liked. For each application I pasted the job requirements into Claude, pasted the text of my CV after them, and asked for the CV to be tailored to the ad: use its keywords, reorder by relevance, invent nothing. Then I copied the result back into Canva.

Three things were wrong with that. There was a lot of manual copying. Pasting the new text into Canva broke the layout every time. And nothing connected the tailored CV to the row in the spreadsheet.

The app began as a replacement for the spreadsheet and grew to cover the rest. What it kept from the manual version is the division of work: the AI writes a draft from my facts, and I read it, correct it and send it. Building that division into a product raised five questions. This page goes through them. For what the product does today, the landing page is the better place.

Human in the loop

People who supervise an automated system tend to accept its output without checking it. A reviewer who only clicks “approve” is in the loop on paper.

So the question was what the person gets to review with. A tailored CV is saved as a draft, and sending it is a separate step that only the person takes. Beside the draft, the app says what it moved, condensed or reworded, and which of the job’s requirements the profile does not cover. Every change the AI makes can be undone, and if you edit the CV while the AI is revising it, your version is kept.

Who answers for the text

When an automated system fails, the blame often lands on the person who was supposed to supervise it, even when they had little control over it. A CV is a different case, because the applicant answers for it anyway. Their name is on it, and they will be asked about it in an interview.

That makes fabrication the main risk. In CV Tailor, the facts you enter in your profile are the only permitted source of claims. The prompt forbids inventing skills, employers, dates or figures, and a job posting is treated as data, so an instruction hidden in an ad is ignored. When the assistant rewrites a duty as an achievement and has no number, it asks for one.

None of this proves that a CV is accurate. A prompt is an instruction, and the model can fail to follow it. The review is the control, and the rest exists to make the review easier.

Numbers that can be checked

A match score written by a language model looks precise and cannot be checked. Here the model never writes a number. It classifies the job’s requirements as met, partly met or missing, and it lists the terms a recruiter would look for. The code counts, and both lists are shown behind the scores.

There are two scores, and they mean different things. One compares the requirements with your profile, so tailoring cannot raise it. The other counts the job’s key terms in the CV, and tailoring raises it by design. The second measures the wording of the CV, and says nothing new about the candidate.

Data minimisation

A CV is nothing but personal data, so the question is who sees which part of it.

Tailoring and matching send the model your facts without your name, contact details or photo. Those are added on the server when the CV is rendered. Importing a CV is the exception: the whole document has to be read once. Each account has its own database file. Usage statistics carry a pseudonymous ID and no content, and error reports are stripped of their text before they leave the server.

A review of my own code found a gap: the raw text of the imported CV was still sent with every tailoring request, so a fact deleted from the profile could come back. It is excluded now.

A budget for the machine

Every AI call costs money, and all of them run on an account I pay for. Each plan allows a fixed number of AI operations, each account has a cost ceiling behind those limits, and a single call that would cost too much is refused before it is sent. A credit is only used when the AI delivered something.

What I would do differently

Ship sooner, talk about it more, and put it in front of people early. I built dozens of features before I knew whether anyone wanted the first one.

I tested with the CVs I had, and those were tech CVs filled in correctly. Real users have other professions and fill forms in wrong. I would test with many kinds of profiles from the start, and make the mistakes on purpose.

I would also measure from the first day. Most visitors leave the landing page after a few seconds, and for a long time I could not say why. I would track what people actually do in the app and test different headlines against each other. More measurement does not have to mean less privacy, but it does mean asking first.

The promise at the centre of the product is that the AI invents nothing, and I never measured it. My automated tests run against a fake AI, so they show that the app works, not that the output is honest. A fixed set of CVs and job ads, checked for invented claims after every change to the prompt, would turn that promise into something tested.

The security review came late, after accounts, payments and email were already built, and it found real problems. Earlier would have been cheaper.