01
The premise was simple. The build was not.
During a layoff, I checked the career site for one of my former employers. Instead of asking me to search by title, it let me upload a resume and see matching openings. That felt like a better starting point, especially for anyone whose experience crosses disciplines or industries.
Traditional job search asks people to name the role before the system can help them find it. That works when a career follows a clean ladder. It works less well when someone has a broad, nonlinear background and may be qualified for roles they would never think to type into a search box.
The clearest proof of the idea:
Project 123 surfaced a Creative Strategist role at a fintech startup at more than 80% match. I would not have searched for that title. I applied, and it led to a first-round interview.02
Job seekers should not need to know the answer before they search.
My resume includes graphic design, art direction, content design, communications, training, strategy, and work across finance, insurance, defense, automotive, and entertainment. A title search usually gives me more design roles. It does not reliably surface content management, training design, or creative strategy roles, even when the actual work overlaps.
The problem was not a lack of keywords. It was that job search systems narrow the search space too early. The title becomes the filter before the candidate's full history has a chance to matter.
Start with a title
"Senior Graphic Designer"
Mostly returns jobs that already use that title.
Start with the person
Resume + location + salary
Ranks direct, adjacent, and unexpected but plausible work.
03
I was designing for careers that do not fit inside one search term.
The primary user was someone with broad or transferable experience whose career did not map cleanly to a single title. I started with five deliberately different resumes so the system could not succeed by learning one profession.
Art director and senior designer
Defense, automotive, entertainment, finance, and political consulting.
Insurance claims leader and attorney
Law degree, three licenses, bilingual, and deep insurance experience.
Copywriter and former touring musician
English degree and fluency in three languages.
Real estate broker
Prior licensing work, professional athlete clients, and business education.
STEM educator
Environmental science background and an earlier nonprofit fundraising career.
Five profiles were enough to expose major problems, but not enough to prove broad coverage. The current logic may still be overfit to those resumes, which is one reason the product remains an alpha.
04
The product had to work inside some very real constraints.
Reliable listings were hard to get.
Few job-search platforms offered practical public APIs, and many terms of service prohibited scraping. The first week was largely spent finding sources that consistently returned current jobs, accurate details, and working links.
Every source described jobs differently.
Titles, dates, salary, remote status, and geography were inconsistent. Even "WA" could mean Washington state or Western Australia.
The alpha prioritized learning speed.
Matching ran in the browser with no persistent resume storage. That made iteration faster and protected the resume, but processing a broad inventory client-side was slow.
This was a one-person product.
I owned the strategy, UX, design, research, testing, and implementation. The occupation taxonomy and synonym logic had to be built and checked manually.
Live LLM matching did not make financial sense.
Per-search token costs could scale into hundreds of dollars. More importantly, early AI tests produced confident but professionally absurd recommendations.
A plausible score was not enough.
Users needed to understand why a job appeared, especially when the title was unexpected.
05
The first version did not need to solve job search. It needed to prove one thing.
Find at least one credible role the user would not have discovered through their normal search.
That translated into five practical product goals:
- Ask for the minimum information needed to begin.
- Search broadly before narrowing.
- Put the most defensible results first.
- Explain every score with visible matching reasons.
- Preserve surprising opportunities without presenting nonsense as insight.
06
The interface took hours. The matching took weeks.
I sketched three boxes and went directly into the browser. The first interface took less than a day. The first week was spent getting real jobs into the product and researching where reliable inventory could come from. The next two weeks were repeated cycles of searching, finding terrible results, changing the logic, and searching again.
I used AI-assisted coding to move from sketch to working software quickly. The product strategy, UX decisions, test criteria, and judgment behind each iteration were mine.
Three boxes and a working interface
Resume upload, location with remote preference, and minimum salary.
Usable pre-alpha
Connected enough job sources to produce real listings and working application links.
Results stopped being terrible
Reworked scoring, occupation relationships, explanations, and edge cases through roughly 50 iterations.
Refinement, not reinvention
Minor interface polish, substantial results-page refinement, more sources, and continued tuning.
07
Key product decisions
Most of the design work was not about the three boxes. It was deciding what the product should infer, what it should explain, and when it should admit that the data was uncertain.
Protect discovery
Do not ask for a job title before showing value.
Title, industry, seniority, company, and employment type were deliberately omitted from the initial flow. Asking for them would recreate the same early narrowing Project 123 was meant to avoid.
Search architecture
Retrieve broad inventory, then rank it.
The available APIs could not support nuanced resume-derived searches. Rather than forcing the resume into a collection of search terms, the product retrieves a broad set of jobs that meet basic location, remote, and salary requirements, then evaluates each one against the candidate.
Matching model
Career plausibility has to come before shared keywords.
The earliest formula was additive. Skills, software, industry, experience, and seniority all added points independently. That made the totals look reasonable even when the job made no professional sense.
The model evolved so occupation relationships shape the value of everything else. Direct roles receive full consideration. Adjacent roles can score strongly. Roles in the same occupational family remain possible. Unrelated professions are heavily penalized, and roles missing a required legal credential are capped.
Contextual skills
Knowing Microsoft Office does not make an art director an executive assistant.
The current version can still overvalue generic tools when they overlap with an industry. The next deterministic rule should interpret a skill through the roles in which the candidate used it. In an art director's history, Office likely supports presentations, budgets, reviews, and communication. It does not establish executive-assistant experience.
MS Office + finance industry = executive assistant
MS Office used within art direction = supporting tool, not occupational evidence
Trust
Make the score explain itself.
An unexpected title can be valuable, but only if the user understands why it appeared. Each result shows the match percentage and the strongest reasons behind it, such as related skills, software, experience, seniority, or industry.
The percentage is a relative confidence signal, not a promise that the person will get the job. A lower score can still be defensible. An absurd score is not.
Uncertain geography
Warn instead of deciding for the user.
Location data from multiple sources is not standardized. "WA" can mean Washington state or Western Australia. Automatically hiding either interpretation could remove a valid role for someone in Seattle or Perth.
The product keeps the listing visible and adds a geographic warning when it detects a potential cross-country issue. This separates uncertainty from error: bad professional matches should be pushed down, but ambiguous data should be surfaced honestly.
AI tradeoff
Do not use AI just because the problem sounds semantic.
I tested AI in two roles: first as a keyword parser and thesaurus, then as a recruiter evaluating fit. It increased cost and still made bad decisions. One version recommended an insurance underwriter role because I was an art director who had worked for an insurance company.
I replaced live AI matching with deterministic rules because they were cheaper, faster to inspect, easier to explain, and more predictable. AI may still help expand the taxonomy and code, but those changes would be reviewed and tested before they reach the product.
Future threshold
Hide weak results only after the score is calibrated.
The alpha still shows the full scoring range because I am watching where the bad matches begin. A future version will use one fixed threshold, set from observed results across a broader set of resumes rather than from an arbitrary number.
When nothing clears that threshold, the product should say so clearly. Users could still choose to reveal the lower-confidence results, with every original percentage intact and clearly labeled below the recommended cutoff.
08
The bad results were the research.
The saved builds show seven major versions. In reality, there were closer to 50 rounds of changes. The strongest product decisions came from watching the system fail in ways that sounded logical to a computer but were obviously wrong to a person.
Graphic designer → nurse
An additive score found enough loose overlap to create a plausible-looking percentage with no professional basis.
Change:Added occupation relationships and credential caps.
Art director → insurance underwriter
The model overvalued a shared industry and ignored the actual function of the candidate's work.
Change:Made shared capability more important than industry.
Art director → executive assistant
Generic software like Microsoft Office still occasionally creates too much evidence for an unrelated role.
Next change:Weight skills and software against the candidate's job history.
The results page changed for comprehension, not decoration.
Matching reasons sat to the right. Long reasons broke outside their bubbles and competed with the listing.
Moving the reasons below created a clear reading order and gave the content enough room to wrap.
Runtime speed vs. learning speed
Keeping matching in the browser made searches slower, but it let me change sources, vocabulary, scoring, and interface logic without first building infrastructure around an unproven idea. For the alpha, I optimized the product for learning speed, not runtime speed.
09
It is far from done, but it works.
After roughly 50 iterations, I ran hour-long searches for seven consecutive days across different resumes and consistently found relevant roles. The interface required no explanation. Testers praised its simplicity and the unexpected but plausible "unicorn" results.
Creative Strategist · Fintech startup
I would not have considered "strategy" in a traditional job search.
Project 123 connected the role to related creative capabilities and prior finance-industry experience. The score and explanation made the move feel credible enough to apply. That application led to a first-round interview.
Occasional irrelevant jobs still slip through because of shared software and industry. My bar for beta is ten pages with no indefensible matches across a much broader range of resumes. The results do not need to be perfect. Every percentage does need to be justifiable.
10
What I learned
A simple interface can sit on top of a very complicated product.
The three-box design was not the hard part. Job supply, normalization, career relationships, scoring, explainability, and edge cases were.
Shared tools do not equal shared professions.
Software and generic skills only become meaningful when they are interpreted through job history and professional context.
False positives are more damaging than imperfect scores.
A user can understand a 68% match. A nurse recommendation for a designer makes the entire system look unserious.
Uncertainty and error need different treatments.
Professionally absurd matches should be penalized. Ambiguous geography should be warned about, not silently removed.
The biggest thing I was wrong about: I thought this would be easy.
It sounded like resume in, jobs out. In practice, it was several difficult systems problems stacked together.
11
What I would improve next
Project 123 is not finished. That is part of the point.