Why One CV Cannot Win Every Job

Most people send the same CV to every job, then wonder why nothing comes back.

The common advice is "tailor your CV to each role." Everyone nods. Almost nobody does it. Not because they are lazy, but because doing it properly, for every single job, takes hours that nobody has. So they go back to one generic file and hope.

That gap, between the right thing to do and the time it takes, is the whole reason I built myCVpath.

A CV Is Not a Record of Your Life

A CV is not a list of everything you have done. It is an argument for one specific job. The moment you treat it as a life record, it gets long, flat, and aimed at no one.

And it has to win over two very different readers, in order.

First a machine reads it. Most companies run applications through software called an ATS, an applicant tracking system. It scans your CV for the words and skills the job posting asks for. If those signals are not there, a human may never see the page at all.

Then, if you pass, a person skims it. They are not reading every word. They are hunting, in a few seconds, for proof that you fit this role.

A generic CV loses both readers. The machine cannot match what you did not say. The human cannot find the proof fast enough, because it is buried under everything else you have ever done.

Tailoring Works. Doing It by Hand Does Not.

A tailored CV beats a generic one. That part is not in question. The problem is what tailoring actually costs you.

To do it right for one job, you have to read the posting closely, work out what it really asks for, dig back through your whole history for the experiences that match, rewrite each line to speak to that role, keep the formatting clean enough for the machine to read, and then do all of it again for the next job. And the next.

Most people manage this once. By the third application they are tired, and the generic file comes back out.

So the real problem was never "should you tailor your CV." The answer to that is obviously yes. The real problem is that the correct move is too slow for a human to repeat every time. That is not a motivation problem. It is a systems problem. And systems problems can be solved.

One Master, Many Tailored Versions

The idea at the center of myCVpath is simple.

You keep one master CV, a single source of truth that holds everything you have done, in full. You only maintain that one.

Then, for each job, the system produces a tailored version from it. It does not invent new experience. It selects from what is already true and rewrites it so the most relevant proof rises to the top for that specific role. Every application keeps its own saved version, so months later you can look back and see exactly what you sent, and to whom.

That line matters, so I will say it plainly: tailoring here means choosing and sharpening true things, never making things up. A CV that lies fails the one job a CV has: to be trusted.

How the Machine Reads a Job

The hard part of this was never the formatting. It was the judgment: out of everything in your history, what actually matters for this one posting?

I did not hand that judgment to a single large request and hope. I broke it into a line of small, specialized steps, each one doing exactly one thing:

• Read the CV and turn messy text into clean, structured data
• Check that structure for gaps and mistakes
• Read the job posting and pull out what it is really asking for
• Compare the two: where you are strong, where you are thin
• Rewrite the CV for that job, keeping every claim true
• Score the result against the posting, so you can see how close the fit is

Each step is narrow on purpose. A small task with one clear question gives a far better answer than one giant instruction trying to do everything at once. The same is true for people. It is true for machines too.

Why It Is Built From Different Parts

There is a habit in software of picking one language and forcing the whole product through it. I went the other way. Inside one product, I used the right tool for each separate job.

• The interface runs on Next.js. The user is in a back-and-forth while tailoring, so the front needs to feel fast and responsive.
• The AI core runs on Go. It coordinates all those steps, holds many requests at the same time, and stays cheap to run under load.
• The document engine runs on Python. Turning structured content into a clean, machine-readable PDF is fiddly, detailed work, and Python has the best tools for it.
• The tracking layer runs on Rust. It records what happens with almost no overhead, so measuring the system never slows the system down.

Four languages, one product, each chosen for what it is genuinely good at. This costs you some simplicity, more moving parts to hold in your head. What it buys you is a system where no single piece is fighting its own tools. For something meant to run for years, that trade is worth it.

What This Is Really About

It is easy to read all of this as "AI writes CVs now." That is not the lesson.

The lesson is older and more useful. When a task is clearly the right thing to do, but too slow to do by hand every time, that is exactly the kind of task worth turning into a system. The value was never in writing one clever CV. It was in making the correct version possible every single time, without losing an evening to it.

The same CV for every job was never the smart move. It was just the only one most people had time for. That is the part worth fixing.