Job hunting is a part time job of mostly wasted motion
You hit the same boards every day. Most of it is noise. You read each posting and guess if you fit. For anything decent, you rewrite your resume and a cold note from scratch. Then you lose track of what you sent and what came back.
The judgment is the valuable part. The searching, the scoring, the rewriting, the tracking, none of it needs you. It just eats your evening.
So I set out to build the thing that takes the grind and leaves you every decision. But before I wrote a line of it, I went and looked at what already exists.
The market, before I wrote a line of code
I mapped what already exists
People already job hunt with AI. So the first move was not to code. It was to look at the tools they use, and find where they fail.
The market splits in two, and neither half is good. Cheap bots spray hundreds of applications a day. They convert below one percent and get you banned for applying faster than a human can. On the other side, human done for you services do real work, but they cost a lot and cannot scale. In the middle sit point tools that each solve one slice and stop.
| Tool | Approach | Fit score | Tailoring | You approve each send | Your data stays yours |
|---|---|---|---|---|---|
| Mass auto appliersLazyApply, Massive | Fires on its own, at volume | None, keyword match | Generic or none | No | No, their servers |
| AI matchersJobright.ai | Discovery, leans auto apply | Percent only, thin reason | Auto, but keyword stuffs | Leans auto | No, US only |
| Resume optimizersJobscan, Teal | You apply by hand | Match rate, explainable | Strong, but all manual | Yes, you do it all | No, their servers |
| Trackers and autofillSimplify, Huntr | Assisted autofill | Basic or none | Basic | Yes | No, their servers |
| Human done for youReverse recruiters | A person applies for you | Human judgment | Yes, by a person | No, a stranger sends | No, you hand it over |
| Job AgentThis build | Assisted. It drafts, you send | 0 to 100 with a written reason | Truthful, tuned per role | Yes, every one | Yes, isolated at the database |
Representative tools per group, from a scan of the 2026 market. Job Agent is the only row built to be strong on the columns that decide whether an application actually lands.
The gap
The market makes you pick one. I built the third option.
Every tool on that board forces a trade. Spray cheap and get ignored, or banned for inhuman speed. Pay a person for real quality and it does not scale, and your whole history lives on someone else's server.
Job Agent takes the middle nobody was serving. A private, single user agent that finds and scores roles with a written reason, drafts a truthful resume for each strong match, and hands every application to you to approve. Quality at software speed, with your data staying yours.
Assisted, not auto. You approve every send.
This is the decision the whole product hangs on. The spray bots apply for you. That is exactly why they get you banned and ignored. So I built the opposite. The agent does everything up to the send, then stops and hands it to you.
The run is a five step loop. It pulls roles from real job feeds and dedups them, scores each one against your resume with a written reason, then branches on your fit threshold so only strong matches move on. For those it drafts a tailored resume and an outreach note, tracks them, and emails a short digest.
A person reviews and submits every application. That is a product decision, not a missing feature. It keeps the quality high and keeps you inside the terms of every job board, the thing that quietly kills the mass appliers.
A fit score you can argue with
Most tools give you a match percentage and no reason, or nothing at all. A number you cannot question is a number you cannot trust. So every score comes with its work shown.
Open any role to see the fit breakdown. The reason it scored the way it did, the skills that matched, the gaps, and the recommended resume variant. You decide fast, and you can close a gap before you ever apply.
Below it, the agent has already written a tailored resume and an outreach draft for that exact role, tuned to the posting without inventing skills you do not have. Applying becomes an edit, not a blank page. Minutes, not an hour.
Your data, walled off by the database itself
Every other tool holds your resume and your whole search history on their servers, and some reuse it to train. For a job hunt, which is private and often something you are doing quietly, that is the wrong default.
So every user's data sits under database level isolation. The database itself refuses to read or write across users. I pushed that rule down to the layer that cannot forget it, instead of trusting my own code to filter correctly on every query. One missed query and a stranger sees your search. Safe by default beats careful by habit.
The tradeoff was more setup and a stricter data model up front. Worth it. Privacy is not a setting here. It is the architecture.
Onboard once, then step back
You upload a resume and tell the agent what you are hunting for. Target roles, locations, salary, company types, deal breakers. This is the only manual setup in the whole product.
After this, the daily run takes over. Everything you see from here is the agent's output, not work you do by hand.
Know if it is working
Analytics turns the hunt into numbers. The pipeline funnel, the spread of fit scores, which sources produce the best matches, and matches over time.
It answers the only question that matters once the agent is running. Is the hunt actually converting. Nobody has to pull a report to find out.
Trust is a feature. I built it like one.
The first version was correct and looked like a raw scaffold. Default font, black on white, no identity. The logic worked. Nobody would hand it their job search.
So I ran a focused design pass. I anchored on a job board feel, light and airy, rounded cards, one signature gradient for the standout match, color coded fit scores. The whole look lives as design tokens in one file, so all eight screens stay consistent and retune from one place.
None of that changed what the agent does. It changed whether a stranger would trust it enough to run it. For a product that handles your career, that is not polish. That is the product.
One instance, one key, an open question
It runs as a single instance on my Google Cloud, on one provider key, so a new user just signs up, uploads a resume, and starts. No keys to wire up, no accounts to create.
Whether to move to bring your own key, where each person funds and controls their own agent, is an open product decision. It removes my cost and usage ceiling at scale, but it adds setup friction, so it only earns its place once there are enough users to justify it.
Each user still sets their own schedule, run now or daily or off, and the daily run takes it from there.
One key should run the whole agent
The first build ran on serverless, and serverless cannot run the embedding model the scoring needs. So the embeddings ran on a hosted OpenAI key instead. That quietly created the thing I hated most about the product.
To run the agent, you had to bring two keys. One for the writing model you actually wanted, Claude or Grok or anything else, and a second OpenAI key only for embeddings, because those chat models cannot embed. Two keys, two accounts, two bills, just to start.
So I moved the whole thing to Google Cloud. The embeddings now run inside the container, on the same machine as everything else, for free. One key runs the entire agent. The database, the auth, the storage, the daily run, all of it sits on Google Cloud and stays free until the traffic grows.
The move was never about the cloud logo. It was the two key problem. Fix where the embeddings run, and the thing that made the product annoying to start just disappears.
What I would prove next
The one number I would chase
This is a working build and a clear thesis, not a company with a user base yet. So the honest next step is a number, not a feature.
I would put the assisted flow against the market's baseline. Mass apply tools convert below one percent. If a small, human approved shortlist beats that by a wide margin on callbacks per hundred applications, the thesis holds. If it does not, the product is wrong, not the code. That is the test I would build the next sprint around.