Tired of the Search.
So I Built the Tool.

Job searching while employed is a second full-time job. A bad one.

I am a senior fintech PM at a large credit union. I spend my days thinking about product strategy, customer behavior, and how to turn complex financial systems into things people actually use. Then I come home and spend 4 to 5 hours doing something I would never accept in my professional work: repetitive, unscaled, manual effort.

The traditional job search is an assembly line where the human is the only moving part. Monitor dozens of career pages. Read hundreds of job descriptions. Write customized materials for each one. Track status in a spreadsheet that goes stale the moment you close it.

The tools that exist either automate the wrong things, or automate nothing. There was no tool that treated job searching the way a PM would design any other workflow: discover, score, tailor, review, and let a human make the final call.

I built the platform before I built the application.

Career Scout runs on Helios, a local-first AI platform I built on a Raspberry Pi 5 before a single line of Career Scout existed. Local LLM inference via Ollama, cloud escalation via OpenRouter, capability-based model routing, a provider abstraction layer, an evaluation framework, and a RAG pipeline.

This was not accidental sequencing. I wanted to build a real AI application, not call an API and pretend. The platform work meant I had to confront the real problems first: when does a local model produce worse output than a cloud model? How do you measure that reliably?

Discovery from three live job-board APIs, deterministic scoring (never "the model decided"), JD-aware materials generation, and a validation pipeline that runs 57 automated checks before anything surfaces to a human.

Step two of the pipeline. Try it yourself.

The scoring engine is the one piece of this system that does not need a live job board, an LLM call, or my Raspberry Pi to demonstrate. It is deterministic: same input, same score, every time. So I pulled it out and rebuilt it as a browser-only prototype.

This is a real piece of the system, not a mockup, but it is a simplified one. The keyword matching behind each factor is illustrative, not the literal production Python. Live discovery, JD-aware materials generation, grounding validation, the 57 automated checks, and the human approval gate are the rest of the pipeline. They are not part of this demo. That full system is what ships with the open-source release.

I wanted Helios to behave like infrastructure, not like a program I happened to run on my laptop.

A dedicated Raspberry Pi 5 gave me an always-on, private, resource-constrained environment where I had to solve real problems: deployment, persistence, reliability, remote access, model routing, storage, observability, recovery, and security. Career Scout was a good first product because it has recurring background work, sensitive personal data, human approval boundaries, and a clear measure of usefulness. Building it on the Pi forced me to design it as a durable system instead of a collection of scripts that only worked when my computer was open.

The hardware constraint also made the architecture better. With 8 GB on a Pi 5, you cannot casually throw infinite compute at a problem. That forces real questions: does this actually need an LLM? Can deterministic Python solve this instead? What model size is appropriate? Those constraints pushed the system toward a much stronger architecture: deterministic policy plus bounded AI reasoning plus durable state plus human authority, rather than LLM all the way down.

Privacy is especially relevant here. Career Scout holds your employment history, compensation context, career goals, application history, interview status, and generated materials. A dedicated machine you control gives you a meaningful privacy architecture by default. And because BlueDemonPi is reachable through Tailscale, Helios lives in one place while you access it from any device, which starts to resemble how an actual hosted product works.

I had the tools to automate the last step. I chose not to.

The most common question people ask is: does it apply for you? The answer is no, and that was a deliberate product decision, not a technical limitation.

Every part of the system up to the moment of submission is automated. Discovery, scoring, materials generation, quality review, validation. The system does all of that. Then it stops, sends a notification to my phone, and waits.

Applying for a job is a commitment. The company on the other side allocates time, energy, and judgment to your application. Automating the submission treats that commitment as a volume play. That is bad product design for the application process, independent of whether the AI output is any good.

The safety architecture enforces this in code, not just in intent. Materials generation, human approval, and marking an application as submitted are three separate, explicit states. Approval is bound to the exact content-hash of the materials a human reviewed. Regenerate the resume after approving it, and the approval is automatically invalidated.

The hardest problem: making an LLM that doesn't invent your qualifications.

JD-aware resume generation sounds simple. Read the job description, tailor the resume, output a PDF. The hard part is that a language model, given the instruction "make this resume stronger for this job," will make it stronger by inventing things.

It will add a percentage you never claimed. It will describe a project with qualifiers you never used. It will introduce a product name from the JD into a sentence about experience at a company that predates that product. It won't lie boldly enough to be obvious. It will lie plausibly enough to matter.

The solution is mechanical grounding validation. Every LLM rewrite is checked against a canonical profile YAML before it is accepted. The check is structural: a new number not in the verified metrics registry is rejected. A company or product name not in the career history is rejected. A qualitative claim not in the source text is rejected.

I tested this against two models before shipping. A cheap model was too conservative to produce useful rephrasing. A stronger model actually worked. That comparison is an evaluation, not a vibe.

I audited my own production system and found three bugs I didn't know existed.

After 207 commits and months of daily runs, I had a working system. Then I stopped adding features and read the code like an auditor. Not a code review, not a test run. A systematic read of every file with one question: what is this code actually doing, as opposed to what I believe it is doing?

"Career Scout" is a placeholder.
The real name is coming.

The system I built has been running internally under the working name Career Scout. That name was never meant to ship. It is a description, not a brand. I am currently testing a new name with a small group of people before I commit to it. When it is right, you will know it when you hear it.

The open-source version will be the full core pipeline: discover, score, generate, validate, surface. The architecture that makes it trustworthy rather than just functional. Free, on GitHub, with clear documentation and a setup path that does not require you to own a Raspberry Pi.

If the community finds it useful and wants more, there will be a paid version with features that should not be free. The shape of that premium tier will come from what people actually ask for, not what I decided they would want before anyone tried it.