Inspiration
I have worked as a Full-Stack .NET developer for around eight years and have applied for jobs in several countries. After moving to Germany, I started encountering a new problem.
A job description could be written partly or entirely in German, but that did not necessarily mean German was required. Sometimes English was the working language. Other times German was merely a plus—or genuinely mandatory.
Repeating this process for every application took time. I wanted a quick second opinion that considered not only language requirements, but also my skills, preferred working style, industries, companies, and deal-breakers.
That is how Apply or Not was born. Although the original problem came from my experience in Germany, the same idea could help anyone applying for roles in another country or language.
What it does
Apply or Not is a browser extension that evaluates the current job posting against criteria written naturally by the user. Users can mention skills, languages, preferred companies or industries, remote-work preferences, application methods, and genuine deal-breakers—even if they ramble.
The extension extracts the job description and available company and application information, then sends the evidence to GPT-5.6 Sol. It returns:
- An Apply, Consider, or Skip recommendation
- A score from 0 to 100
- Positive matches and concerns
- Hard blockers and uncertainties
- Evidence from the original posting
- Detected language and explicit language requirements
It analyzes the posting in its original language and explains the result in the user’s preferred language. Importantly, it does not assume that German is required simply because the description is written in German.
It also recognizes transferable experience. For example, SQL Server experience remains relevant when a role mentions PostgreSQL.
The result is decision support—not the final decision. Its purpose is to help users identify promising roles that deserve a closer look.
How we built it
I built Apply or Not incrementally with Codex using GPT-5.6 Sol. I described the desired behavior in small steps, tested each version in Safari and on real job pages, and brought back bugs or misleading behavior for another iteration.
The extension uses plain HTML, CSS, and JavaScript without React, bundlers, or a build pipeline. Its browser-neutral WebExtension core supports Safari, Chromium, and Firefox.
Job information is extracted using visible page content, Schema.org JobPosting data, generic selectors, and job-site-specific patterns. A background worker manages analysis so closing the popup does not cancel an active request.
A localhost Node.js relay keeps the OpenAI API key outside the extension and browser storage. It sends non-stored requests to the OpenAI Responses API and validates structured GPT-5.6 output against a strict schema.
GPT-5.6 interprets contextual evidence, while trusted application code calculates the final percentage using a fixed rubric. Results are cached locally so reopening the popup does not create another billable request.
Challenges we ran into
Job sites structure their pages differently, and many load content dynamically. Even identifying the selected LinkedIn job was challenging because unrelated job cards could contain misleading controls such as Easy Apply.
Scoring also required more than asking the model for an arbitrary percentage. Reanalyzing unchanged evidence could otherwise produce noticeably different results. We introduced fixed rubric dimensions and deterministic application-side scoring while keeping GPT-5.6 responsible for contextual interpretation.
Language needed careful handling. The posting language, the user’s proficiency, the requested explanation language, and an employer’s actual language requirements are four separate facts.
Browser-extension popups are temporary. Initially, closing the popup also interrupted analysis. Moving the work into the background allowed users to continue reading and reopen the result later.
Other issues discovered through real testing included slow popup scrolling, stale cached results, incorrect Easy Apply detection, Safari password-manager prompts, API failures leaving an old toolbar score, and closed listings receiving positive scores. Closed applications now deterministically receive 0 · Skip, regardless of technical fit.
Accomplishments that we're proud of
I am proud that Apply or Not became a coherent working product rather than just a prompt attached to a popup.
It includes multilingual analysis, editable free-form preferences, evidence-based explanations, deterministic scoring, background analysis, local caching, billable-reanalysis warnings, company evidence, application-method detection, and a toolbar badge.
The API key is never embedded in the extension or saved in browser storage. The relay holds it only in memory and forgets it when the process stops.
The project also includes four polished fictional job scenarios and a clearly labeled no-cost demo that judges can run without an API key or network request.
Most importantly, repeated hands-on testing resulted in 55 automated regression tests covering extraction, scoring, caching, provider responses, security, browser compatibility, and previously discovered bugs.
What we learned
I learned that building a useful AI product requires more than connecting an interface to an LLM. The model is valuable for understanding context, ambiguity, multilingual text, and transferable skills, but important product rules still need deterministic safeguards.
I also learned how different a browser extension behaves from a normal webpage. Popup lifecycles, permissions, dynamic job pages, background processing, caching, and cross-browser manifests all introduced challenges that were not obvious initially.
Working with Codex was most effective as an iterative collaboration. Codex accelerated implementation, refactoring, testing, and documentation, while I tested the product, identified incorrect assumptions, and made the product and design decisions.
What's next for apply-or-not
The next major step is supporting local LLMs through configurable OpenAI-compatible endpoints such as Ollama or LM Studio. This would give users another privacy-conscious option without requiring a cloud API key.
Other planned improvements include:
- Dedicated adapters for Indeed, Glassdoor, Xing, and additional job sites
- Translation and explanation of dynamically generated application-form labels
- Optional company enrichment with visible sources and confidence
- Configurable score thresholds and weighting preferences
- A privacy-conscious hosted relay with quotas and cost controls
- Continued improvements based on real job-page testing
Log in or sign up for Devpost to join the conversation.