Career Ops, an open-source job-search pipeline I priced and gave a front end

It refuses to answer the obvious question

The engine never asks “what is this role worth?”, because that is a number anyone can argue with. It asks whether the role beats the best alternative I could already get, plus a premium for taking on the risk of a smaller company.

The baseline is a knowable number

The best alternative is a big-company role at my level. That is a real, checkable figure, and it anchors everything else. Cash compares to it directly.

Equity is never assigned a value

Instead the engine works backwards. The cash falls short of the baseline by some gap, and the shares are priced at the company’s own last round. So how much must the company grow for the equity to close that gap? That required growth is then compared against what companies at that stage actually do, from a base-rate table. Required growth far above the base rate means I would be paying to take their risk.

Two modes, one engine

While searching, a posting rarely states equity, so the output is a clearly labelled market estimate whose only job is to rank a pipeline. Once there is a real grant on the table, the estimate is dropped and the real verdict runs: lowball, fair, or highball, with the specific ask that would close the gap.

Confidence is the weakest link, not the average

Level, baseline, and equity each carry their own confidence, and the overall confidence is the lowest of the three. Averaging them would let two strong inputs hide one guess.

A posted band always wins, if it is plausible

When an employer publishes a salary range, its midpoint overrides the model. But an hourly band would otherwise feed the engine a $50 base and produce a confident near-zero total, so a band is only trusted as a base when it reads like an annual figure. The raw band string is stored either way.

Fork, do not rebuild

Start from an open-source job-search pipeline rather than writing one, and keep taking upstream releases.

WhyThe unglamorous 80% — applicant-tracking-system parsers, deduplication, the tracker format, document generation — was already solved and is maintained by people who see far more hiring portals than I do. My time was better spent on what was missing.

Trade-offEvery enhancement I make has to be replayed on each upgrade. That recurring cost is exactly why my changes stay surgical instead of sprawling.

Multi-user by path, not by rewrite

One environment variable selects whose CV, filters, and tracked companies a run uses. The repo holds the system; a folder outside it holds each person’s data. Unset, it behaves exactly like the single-user original.

WhyMy partner needed the same pipeline pointed at different targets. A fork that diverges structurally from upstream cannot take upgrades, so the change had to be additive.

Trade-offEvery per-user path has to resolve through that variable, and getting one wrong would silently mix two people’s data. The startup check resolves the user directory first and fails loudly if it is missing.

Two run contexts, one pipeline

The same steps run interactively with a human in the chat and headless under the control plane. In the headless path, any gate that would have waited for input records its outcome and moves on.

WhyAn unattended nightly run that stops to ask a question is not paused. It is a job that failed slowly, and I find out in the morning.

Trade-offDecisions that genuinely need judgment have to be re-surfaced in the UI later instead of being resolved in the moment.

Compensation is displayed, never scored

The estimate is a sortable column, and it is explicitly excluded from the fit score.

WhyIf pay feeds the score, the pipeline starts recommending well-paid roles I do not want. The score answers “is this a fit”. The comp answers “is it worth it”. Collapsing them into one number destroys both.

Trade-offI read two numbers instead of sorting by one.

Never invent a number

When the engine cannot price a posting it returns nulls plus a status saying why — no profile, no data, or a real error — and the row shows no estimate.

WhyAn estimator that guesses when it does not know is worse than no estimator, because you can no longer tell the guesses from the reads.

Trade-offPlenty of rows show no compensation until the cache has data for that company. An empty cell is the honest answer.

Crash-proof the wrapper, not the engine

The comp step exits non-zero only when I have called it wrong. Every data outcome exits cleanly with a status carrying the truth.

WhyCompensation is one field on an evaluation. A pricing failure must never fail the evaluation around it, or one bad company kills the night’s run.

Trade-offA genuine engine bug can hide behind a status code, so schema drift is logged loudly to standard error rather than swallowed.

The voice pass runs downstream

The cover letter is drafted, the session ends, and only then is the letter rewritten through a separate voice pass.

WhyThe drafting model optimizes for covering the job description. Voice is a different objective, and asking for both at once means voice loses every time.

Trade-offAnother step that can fail, plus a backfill script for letters written before the pass existed.

Deterministic where it can be, agentic where it must be

Scanning, filtering, deduplication, freshness, and document rendering are plain code. The model is used only where judgment is genuinely required: reading a job description against a CV, and writing.

WhyA model call per posting across roughly 120 companies every night would be the whole cost of the system, and it would be the least reliable part of it.

Trade-offThe deterministic layers need a real parser per portal, and a portal that changes its markup breaks loudly until I fix it.