AI CV Builder

This came out of a previous build rather than out of a problem I was living with.

MyOS had taught me what a closing window costs, because I'd put real effort into something with a natural expiry date, so I went looking deliberately for a problem that would still be around in a few years, not just a few months. Job applications qualify: people are always applying for jobs, more so at the moment, and by now everyone is using AI to write their CV while everyone on the other side of the desk is using AI to screen what arrives. That gave me something worth building: a tool that tailors a CV to a specific role and, just as importantly, gets it through the screening layer rather than dying in it. I'd been through a run of applications myself, so I could use my own product on my own problem.

Distribution shaped this build from the first day, because distribution had beaten me before and I needed something more sustainable than manually posting into threads. I structured the site so that an LLM reading it would understand what the product was and suggest it when someone asked, and I wrote around forty articles targeting the terms people actually search, so traffic would arrive on its own rather than depending on me showing up to chase it.

That keyword work ended up making the product decision for me. The resume space is saturated, whereas CV, which is the UK term, was far less contested, so I went UK-only. What looked like a language distinction turned out to be a real product one: UK CVs don't carry a date of birth or a photograph, and a UK screener will reject exactly the things an American-trained tool would cheerfully add.

From there it became an algorithm problem. I had to work out how a screening tool actually parses a CV, and therefore how mine needed to structure and format one, then take the job link, extract what the role genuinely wants along with a read on which tracking system probably sits behind it, and map all of that against the person's existing CV. The part I cared about most was the interface, because I didn't want it to hand people a finished document from nowhere: it shows you how to reword what you'd already written, and points at roles you've held where there's almost certainly relevant experience you never thought to include. Sitting on top of that was the bigger idea, a platform where you run the whole search, with a tailored CV per application and each one tracked through to interview prep.

The distribution engineering was easier than I'd expected, and mostly came down to structuring the site so another model could read it and then writing content that people were already looking for.

The genuine surprise was in model choice, because the more capable model produced worse results. It was slower, and it drifted further from the required output structure, which is the structure that gets a CV shortlisted in the first place, so the less capable model held the format and won on the thing that mattered.

Traffic was decent, particularly to the articles, and I got 22 sign-ups, which meant the low-effort distribution channel worked and that was the thing I'd set out to prove. I also had data showing that both Gemini and ChatGPT were recommending it when people asked, which was the specific bet I'd made when structuring the site.

I used it myself for an application and it got me an interview. I didn't use it for the next one, because that job mattered more to me, which is a fact about my own confidence in it that I should probably sit with rather than skate past. I also went as far as exploring a faceless Instagram channel to push volume, and then stopped, partly because of the same old question of how much I care about this problem (not much) and partly because I didn't want to be the person running a content channel whose only purpose is hooking people in.

Choosing an evergreen problem fixed the flaw in the last build, and designing distribution into the thing from the start rather than bolting it on afterwards is clearly the right order to work in.

The other half of it is that until I build something I'm willing to devote a decent chunk of time to, the distribution has to be easy, because I'm not going to sustain the manual version alongside everything else. That's part of a growing realisation across all of these: when you can build anything, the question that actually matters is what you should build, because time is the rate-limiting step now rather than capability.

Start at the cheapest, simplest model that solves the problem in front of you. It's easy to get distracted and reach for the most powerful thing available on the assumption that more capable means better output, but that assumption didn't hold here. The bigger model was slower and less accurate at the job I needed doing, and it's always more expensive.

Across thousands of staff that stops being a preference and becomes a cost line with a lot of zeros on it, so the discipline is to ask what the cheapest thing that works looks like, and only move up the ladder when you can demonstrate that it doesn't.

There is nowhere near enough focus on development and maintenance cost when teams are solutionising, and most people, me included in this example, jump straight in without the data they'd need to do an honest ROI calculation from the outset.