Inspiration
Job Radar started from a problem I was experiencing personally.
I am currently looking for my first professional opportunity in data and technology. The process required checking several job platforms, filtering out senior or unrelated positions, opening the same postings repeatedly, and manually keeping track of the opportunities that interested me.
I originally created a small Python script to reduce that repetitive work. During OpenAI Build Week, I decided to turn it into a more complete desktop application.
What it does
Job Radar collects and organizes job opportunities according to a personalized candidate profile.
Users can define their target roles, areas of interest, skills, experience level, locations, work modes, languages, and optional advanced preferences.
The application supports different types of sources:
- Direct job portals
- Applicant tracking systems such as Lever and Greenhouse
- Optional Apify-powered sources such as LinkedIn and Indeed
- A completely offline sample for testing without credentials or external costs
Job Radar normalizes and deduplicates the postings, evaluates them against the active profile, and organizes them into Priority, General, Exploratory, Review, and Rejected categories.
For every result, the application explains why it was surfaced by showing matches such as roles, skills, location, experience level, and desirable requirements.
The user always remains in control. Job Radar does not automatically apply to jobs. Users can review results, open the original posting, save opportunities, dismiss unsuitable jobs, add personal notes, and export complete runs to Excel or CSV.
How I built it
Python remained the core of the project.
The desktop interface was built with Flet, local persistence uses SQLite, and the final application was packaged as a Windows executable. The project also includes automated tests, database migrations, offline sample data, source-specific configurations, and release documentation.
I used GPT-5.6 to analyze the original project, clarify the product decisions, define requirements, and divide the implementation into controlled phases with explicit acceptance criteria.
Codex worked directly with the real repository. It inspected the existing codebase, implemented the V4 desktop application, added persistence and migrations, improved the user workflow, created regression tests, debugged functional issues, prepared documentation, and packaged the executable.
The final repository passes 169 V4 tests and 29 legacy V3 tests.
Challenges
The most difficult part was not simply collecting more postings. It was making inconsistent data from different sources understandable and useful.
External sources can fail independently, job descriptions use inconsistent terminology, and candidate-profile rules can become too restrictive when they are not configured carefully. The application therefore needed isolated source failures, explainable results, configurable profiles, and an offline workflow that evaluators could run without external services.
Another challenge was packaging SQLite migrations and sample resources correctly inside a standalone executable.
What I learned
This project taught me that AI-assisted development works best when the work is divided into explicit phases with constraints, tests, checkpoints, and human validation.
GPT-5.6 helped me turn product ideas and observations into structured engineering requirements. Codex helped me apply those decisions to a real repository while preserving the existing project and validating each phase.
I also learned that the user experience and the quality of profile configuration are as important as the data collection itself.
What's next
I plan to continue improving profile guidance, classification quality, multilingual matching, source reliability, and the execution-progress experience.
Job Radar began as a small personal script, but OpenAI Build Week helped me transform it into a tested, documented, and functional desktop product.
Log in or sign up for Devpost to join the conversation.