Job hunting: How I scaled my personal tool for anyone to use

A few days ago I wrote about a tool I built to help me find work: a scraper that pulls listings off job boards, a local AI that reads the survivors against a brief and tells me how good a fit each one looks, and a dashboard to keep track of it all. I wrote it up because I thought it was a neat little machine. I did not expect people to be so excited about it.

The replies were all some version of the same question. How do I build that? A few people I know are out of work too, or unhappy where they are, and the wading-through-listings problem turns out to be everyone's problem. They didn't want to read about my tool. They wanted it pointed at their own search.

And that's when it hit me that I'd built something with an audience of exactly one. It'd be far more useful with an audience of many. Vibe coding, for me, is like building with Legos. Except instead of Legos I'm snapping together little programs to solve whatever's nagging me. So of course this one was built around my problem. The brief the AI judged against was my brief: my roles, my dealbreakers, the companies I'd never work for. Hard-coded to me. Sharing the idea was easy. Sharing the actual thing meant pulling myself out of it.

Making the engine work for anyone

The scraping, the local model, the scoring — that part already worked, and it works the same no matter whose jobs it's reading. A scraper doesn't care who you are. The problem was everything that was me.

So I took my brief apart and looked at what it actually contained. Who I am in a sentence. The roles I want, best first. The search terms to feed the boards. Where I'm looking, and how I feel about remote. The instant-no dealbreakers. A little rubric for turning a judgement into a score out of a hundred.

None of that is special to me. It's a shape. Everyone job hunting has one; they've just never written it down. So I turned each piece into a question and built a short first-run interview. You answer who you are and what you're after and where, and the tool writes your version of the brief for you. The interview is the whole trick. It's the thing that turns my tool into your tool without either of us touching code.

The repo ships with an example brief. It belongs to an imaginary backend developer who wants remote Python work — somebody who doesn't exist, chosen precisely because he isn't me. That placeholder is the entire point of the project in one file.

It has to run on a machine I'll never see

When software is for you, you are the support team, the install instructions, and the person who knows which step to skip. When it's for a stranger, none of that is in the room. The tool has to carry all of it itself. So, I put on my tech writing hat and started thinking about the shape of making this work for a stranger.

The whole thing runs on your own Mac — the model, your CV, your answers, all of it stays local and never leaves the machine. I thought of it this way for two reasons. The first is that you don't need to pay a company for an AI model. The second is for you to know that nothing leaves your machine — not your preferences, not the companies you don't want to work for, not anything.

I made the install deliberately manual because I wanted you to know that JobScout will never quietly install things on your behalf, and it will never pipe a script off the internet into your shell. That's exactly the type of thing you should be suspicious of when a stranger hands you software. And because I don't know which local LLMs are good or bad, I built it to check how much memory your Mac has and recommend one of two models I personally tested and can vouch for. This way, you don't have to decide which random LLM to install only to discover after the fact that it doesn't work.

A lot of this is invisible when it works, which is the tell that it's the real work. It's the same instinct I've leaned on for years as a writer: the reader shouldn't have to trust you, you should remove every reason for them not to.

The small feature I'm fond of

A run takes a while. A few dozen minutes depending on how fast your machine is and how large a pool of countries you ask it to search jobs in. The model has to read job ads one at a time, which is slow, and these models lean hard on your hardware. Because I don't enjoy sitting in front of the screen looking at the terminal while the script runs, I didn't want anyone else to either. So I added an optional step you can set up to buzz your phone when it's done: new matches to look at, nothing today, or something broke. Three messages, and that's it.

It pings your phone through Ntfy.sh, an easy, free notification service. Because in the free version the channel it uses is, in principle, readable by anyone who learns its address, the notification never mentions a company, a job title, a count, a link, or even what went wrong. Just "go look" or "don't bother." The tool explains how this all works and advises you to create a long, hard-to-guess link, but because it's still your personal data I didn't want it to broadcast anything personal.

Giving it away

After making the tool configurable and not about me, what's left is something that doesn't know or care who I am. And I'm finding I enjoy this part, handing off a tool that's helped me so it can help someone else, even more than I enjoyed building it.

You answer a few questions, and it goes to work on your search instead of mine. Hopefully it makes your job hunt a little less soul-crushing.

You can download JobScout on my GitHub repo.