I built the job-search tool I wish I'd had

For fifteen years my job has been to govern other people's releases — to decide when something is ready, what risk we're accepting, and who has to be in the room when it ships. When I found myself open to my next role, I did the thing I tell every engineer to do: instead of waiting, I built the tool I wished existed.

That tool is Trevo.work — an AI job-discovery engine for the Israeli tech market. This is what I learned building it, and why I think it ended up with the most complete job-seeker toolset I could find anywhere.

The job search is a data problem wearing a UX problem

Looking for a role in Israeli tech means refreshing fifteen different career pages, each on a different applicant-tracking system, each with its own idea of what "Tel Aviv · Hybrid" means. The same job is posted three times under three company names. The interesting roles are buried under aggregator spam. You are doing manual ETL with your eyes.

So the first half of Trevo is exactly that — ETL, done properly:

• A Python collector pulls from 15 sources — Greenhouse, Lever, Ashby, Comeet, Workday tenants, BambooHR, Workable, LinkedIn, and the big Israeli boards — on a 4×/day schedule.
• Each source is isolated: one adapter failing never takes down the run. That's a release-governance instinct applied to a scraper — partial success beats all-or-nothing.
• A dedup layer folds duplicate postings across sources into a single canonical job, with a priority order so a native ATS posting always wins over an aggregator's copy of it.

None of that is glamorous. All of it is the difference between "500 results" and "the 12 roles that are actually real and actually for you."

Discovery is table stakes. The toolset is the product.

Plenty of sites can list jobs. What I couldn't find was a tool that helped once you'd found the job — the part of the search that actually drains people. So the second half of Trevo is a workbench:

• CV analysis and personal fit ranking — your CV and saved searches score every role, so the list is sorted by you, not by recency.
• A per-job ATS CV builder that generates a complete, truthful, ATS-structured CV tailored to one specific posting, with real .docx and print-to-PDF export.
• Interview prep and salary benchmarking for the role in front of you.
• A research-grounded career-fit assessment for the harder question underneath the search: is this even the right direction?

The goal was never "more jobs." It was to compress the distance between seeing a role and being ready to apply for it from an afternoon to a few minutes.

The engineering decisions I'd defend in a review

Building solo doesn't mean building loose. The architecture choices were the same ones I'd push for on any team:

A provider-agnostic LLM layer. Every model call goes through one seam with an ordered failover chain — Gemini → OpenAI → Claude. When a provider deprecates a model overnight or hits a spend cap (both happened), the system degrades instead of dying. I learned that one the hard way: an early version hard-coded a model name in three places and burned a day and a half of silent failures before I centralized it. One constant, one error path, one alert.

Privacy as a constraint, not a feature bullet. Users can bring their own API key — encrypted at rest with AES-256-GCM — so their data runs on their own provider account. CVs are never sold or used commercially. Every new user is still manually approved. For a product built on people's career data, "trust me" isn't an architecture.

Telemetry that can't take down the thing it measures. Every event write is best-effort and isolated. Observability should never be the reason a user's request fails — a lesson that transfers directly from production QA.

Bilingual from the foundation. The whole dashboard is Hebrew-first RTL with English as a first-class locale, not a bolted-on translation. Direction and content language are handled at the source, because retrofitting bidirectional text is its own special kind of pain.

The stack itself is unremarkable on purpose: Next.js on Vercel, Supabase Postgres as the single contract between the collector and the dashboard, a Python service doing the heavy collection. Boring infrastructure so the interesting work can be reliable.

What building it taught me about my own discipline

I expected to learn the AI SDKs. I didn't expect to re-learn how much of quality leadership is just building.

Every gate I've ever designed for a team showed up again, smaller and sharper, when I was the only person between the code and the user: define "done" before you start, make failure partial instead of total, instrument before you optimize, and never let the thing that watches the system be coupled to the system. Shipping solo is the most honest review of your own engineering judgment you can get — there's no one else to catch the shortcut.

Trevo.work is live, in daily use, and still growing. If you're searching for a role in Israeli tech, I'd genuinely like you to try it. And if you're building a team that treats delivery and quality as engineering disciplines — and increasingly, as products in their own right — that's exactly the kind of room I want to be in next.