Case study
Job Radar
A private production system for finding, evaluating, and preparing for the right opportunities—without automating the judgment that matters.
Independent production project · Solo, AI-assisted development
I needed a workflow I could trust
A useful job-search system needed to do more than collect openings. It had to identify relevant roles beyond title keywords, retain what I had actually evaluated, connect an application to the exact posting that prompted it, and recognize when prior activity should affect a future alert.
Without a durable thread between those stages, I repeatedly had to reconstruct the same facts from changing career pages, alerts, notes, and files: what had changed, why the role mattered, and what I had already done.
I did not want a system that would apply automatically or make pursuit decisions for me. I wanted one that could preserve evidence, reduce repetitive work, and help me make better-informed decisions without taking those decisions away.
What I built
Job Radar creates that durable thread.
Search runs as a scheduled service on my private server, where it monitors selected career pages, preserves posting history, evaluates potential matches, and sends alerts with persistent identifiers. Application Prep uses a verified read-only copy of that history while keeping sensitive career evidence, application materials, and private activity on my Mac.
Only a minimal engagement summary returns to Search, allowing future alerts to reflect relevant activity without exposing the underlying private data.
System at a glance
- Career pages → Search on private server
Search monitors public postings, preserves history, evaluates matches automatically, and sends alerts. I evaluate the opportunity and choose whether to pursue. - Search → Mac: Verified read-only copy
Application Prep can read Search history without changing its authoritative record. - Application Prep on Mac
Research, prepare materials, and track activity. I approve facts, approve materials, and decide whether to submit. Submission is a separate human action. - Mac → Search: Only a minimal engagement summary
Private career evidence stays on the Mac. - Return to contextual Search alerts
Future Search alerts gain relevant context from the minimal engagement summary.
Project overview
- Current state
- Deployed and operating across a scheduled private-server service and a local Mac application-preparation workflow.
- My role
- Product definition, requirements, system and workflow design, implementation direction, review, validation, deployment, and ongoing production ownership.
- Development approach
- ChatGPT supported planning and architecture exploration, while Codex performed much of the direct repository implementation. I made the final design and product decisions, validated the resulting behavior, and accepted responsibility for the operating system.
Technical detail: Stack and deployment
Job Radar is a Python command-line application backed by SQLite. Search adapters monitor Greenhouse, Lever, Ashby, and selected static career pages. A Dockerized Search service runs on TrueNAS, while Application Prep and its private Career data remain on my Mac.
Search creates a verified SQLite replica for local consumption. Application Prep uses ReportLab to render résumé PDFs and extracts their text for ATS inspection. A small JSON projection carries permitted engagement state in the opposite direction.
The deployment reflects the workflow rather than forcing every responsibility into one runtime: scheduled public-source monitoring belongs on the always-available server, while private and human-directed application work belongs on the Mac.
Five decisions shaped the system
- Preserve human judgment inside an automated workflow
- Preserve provenance across changing sources
- Separate systems according to privacy and responsibility
- Share only the minimum useful state
- Make reliability and recovery visible
Together, these decisions show how I approach ambiguous systems work: define what must remain true, make ownership explicit, accept tradeoffs deliberately, and validate the result beyond the happy path.
Evidence note: Screenshots and application outputs use a fictional candidate, employers, and job-search history generated by the production application. No private career or application data is shown.
Decision 01
Preserve human judgment inside an automated workflow
A job search combines repetitive work suited to automation with decisions that represent me externally. I designed Job Radar to assist with the first category without inheriting authority over the second.
| Constraint | Decision | Accepted tradeoff |
|---|---|---|
| Application preparation benefits from automation, but its output represents me. | Automate assistance while reserving approval and submission for me. | More deliberate checkpoints than an end-to-end automated workflow. |
Search can evaluate potential matches. Application Prep can assemble evidence, structure drafting tasks, validate content, render a résumé, and extract an ATS preview. AI can assist with research and drafting.
I decide whether to pursue an opportunity, which facts can be used, whether the materials are ready, and whether anything is submitted.
Those checkpoints add friction, but they prevent speed from being mistaken for trust. The result is faster preparation without allowing unreviewed output to become an accepted fact or external action.
Human-controlled automation
- System prepares
- Observe and preserve postings
- I decide
- Choose whether to pursue
- System prepares
- Pin the selected evidence
- I decide
- Review research and apply decisions
- System prepares
- Validate, render, and ATS-check materials
- I decide
- Explicitly approve the materials
Approved ≠ submitted
- System prepares
- Preserve application state
- I decide
- Submit separately—or do not submit
Résumé and ATS preview
Readable résumé
Selectable ATS excerpt
MORGAN COLEMAN Product Operations Manager | Workflow Systems and Operational Analytics PROFESSIONAL SUMMARY Operations leader with experience delivering multi-site workflow systems, adoption, and measurable process improvement.
- Automated checkRendered successfully
- Automated checkATS text validated
Technical detail: Protecting canonical career evidence
Career evidence remains canonical and separate from generated material. A drafting task contains approved evidence and explicit instructions rather than granting the model unrestricted access to the private Career database.
AI-assisted work returns as structured draft content. Application Prep validates that content before it can enter the rendering workflow; a plausible paragraph is not accepted merely because it reads well. Draft content, render records, and approved materials remain distinguishable states.
The renderer creates a deterministic PDF from the validated content. Job Radar then extracts text from the produced file so I can inspect what an applicant-tracking system is likely to receive, not only what the designed page looks like. Final approval occurs after both views are available.
Decision 02
Preserve provenance across changing sources
Career pages are not stable records. A posting can be edited, closed, or reposted, and a company name plus job title is not enough to identify the exact opportunity I evaluated.
| Constraint | Decision | Accepted tradeoff |
|---|---|---|
| Source postings change, while an application must retain its original basis. | Begin every application from a persisted match and pin the originating posting snapshot. | Maintain explicit identifiers and history instead of relying on copied text. |
Each alert includes a persisted Match ID. When I decide to pursue a role, Application Prep starts from that match, creates a durable application identity, and pins the exact posting snapshot that informed my decision.
Search can continue observing the source afterward. If the posting changes, the application retains both the version that prompted it and the newer version now available.
This requires more structure than saving a job description in a file. I accepted that cost because provenance is only useful when it survives changes to the source.
Alert to application
At selection
- Date
- April 6–7, 2026
- Employer
- Northline Relay
- Role
- Product Operations Manager
- Role fit
- 80
- Snapshot
- Snapshot 2 pinned
Match rationale preserved
- Strong title match
- Workflow delivery / requirements delivery / operational analysis
- Adoption enablement
Later observation
- Date
- April 14, 2026
- Employer
- Northline Relay
- Role
- Product Operations Manager
- Role fit
- 80
- Snapshot
- Current snapshot: 5
- Change
- Description updated · Updated: description
Same posting · Original evidence preserved
Technical detail: Snapshots, matches, and durable application identity
A posting identifies the opportunity observed at its source. A snapshot records what that source contained at a particular time. A match records the result of evaluating a specific posting snapshot against my search criteria.
Application creation begins with the Match ID rather than a typed company name or title. The resulting application stores its originating match and pins the corresponding snapshot. Later matches or snapshots may be linked without rewriting the original handoff.
Original and current source state
Editorial extraction from the synthetic application view:
Origin Match ID: 2 Pinned snapshot: 2 Selected: 2026-04-07 Current Search snapshot: 5 Recent Search event: UPDATED Observed: 2026-04-14
The workflow rejects identifiers that belong to a different posting and treats repeated creation requests safely. Application status can display the pinned version beside the current Search version, preserving both historical provenance and present-day awareness.
Decision 03
Separate systems according to privacy and responsibility
Search needs to run on a schedule and retain public posting history. Application Prep contains sensitive career evidence, tailored materials, private notes, and employer activity. Placing everything in one database would simplify the architecture while unnecessarily expanding access to the most personal information.
| Constraint | Decision | Accepted tradeoff |
|---|---|---|
| Search needs scheduled availability, while private career data belongs in a local, human-controlled environment. | Give Search and Application Prep separate data authority. | Add a verified handoff between systems instead of sharing one database. |
Search runs on my private server and remains authoritative for postings, snapshots, matches, and alerts. Application Prep runs on my Mac and remains authoritative for career evidence, applications, materials, and activity.
The Mac receives a verified read-only copy of Search history. It can use that information without modifying the authoritative record, while Search never receives the private career database.
This separation creates additional operational work: replicas must be transferred, verified, and checked for freshness. I accepted that complexity because system convenience was not a sufficient reason to broaden access or blur ownership.
Technical detail: Read-only replication and data authority
After Search evaluates new and changed postings, it creates a SQLite replica using the database backup interface and publishes a corresponding manifest. The manifest records the replica’s generation time and SHA-256 checksum.
The Mac pull workflow transfers the database and manifest as a pair, verifies their integrity and freshness, and installs them together. If the verified replica is already current, the operation completes as a safe no-op. An incomplete or unverifiable transfer does not replace the last trusted local copy.
Application Prep reads Search data through the configured replica but has no path for writing changes back to the authoritative Search history. The private Career database is never copied to TrueNAS.
Decision 04
Share only the minimum useful state
Separating Search from Application Prep protected private information, but it created a useful constraint: Search still needed enough awareness of my activity to avoid sending alerts without relevant engagement context.
| Constraint | Decision | Accepted tradeoff |
|---|---|---|
| Search benefits from limited engagement awareness but does not need private application data. | Publish a minimal, disposable projection instead of copying the Career database. | The projection requires deliberate publication and can temporarily lag behind local activity. |
Application Prep generates a small projection containing only the engagement facts Search needs. Career evidence, research, materials, and private notes remain on my Mac. The local database stays authoritative; the projection is derived, replaceable, and cannot modify its source.
Because publication is deliberate, Job Radar reports whether the projection has never been published, contains unpublished local changes, or is current. Search can warn when the projection is unavailable without losing its ability to monitor postings and send alerts.
I accepted the additional publication step because useful integration did not require unrestricted data sharing.
Private source and safe projection
Private Career system — stays on my Mac
- Application dates
- Internal application IDs
- Notes
- Employer responses
- Interview details
- Materials and approval state
Minimal projection — only this crosses
Private Career system → minimal projection
- Posting identity
- Engagement status
Search annotation — useful context
Minimal projection → Search
- Civic Thread Software: Already applied
- Northline Relay: Already applied
- Ternary Grove Energy: None
Private database shared: No · Projection status: Current
Technical detail: Projection states and publication verification
Application Prep derives the engagement projection from the private Career database. The artifact contains a schema version, generation metadata, verification hashes, and only the application state required by Search. It can be deleted and regenerated without becoming a second source of truth.
Job Radar distinguishes three publication states: never_published, unpublished_changes, and current. A content hash identifies meaningful changes in engagement, while artifact-level verification protects the transferred file itself.
Northline Relay: publication-state comparison
Before publication
- Private state:
applied - Installed state:
in_progress - Status:
unpublished_changes
After verified publication
- Installed state:
applied - Search:
Already applied - Status:
current
Job Radar detects when the privacy-safe projection no longer reflects the private source. Publication is confirmed before the projection is treated as current.
Publication stages the new projection on TrueNAS, verifies its checksum and expected permissions, and replaces the prior artifact only after verification succeeds. Application Prep records publication as confirmed only after the remote copy has been independently verified.
Search treats the projection as optional enrichment. Missing, stale, or malformed content produces explicit status or warning behavior without granting the projection authority over Search or preventing the core monitoring workflow from continuing safely.
Decision 05
Make reliability and recovery visible
A scheduled system can appear reliable while silently using stale data, losing a trusted file, or skipping part of its work. I wanted failure to produce an observable state and a defined response rather than an ambiguous result.
| Constraint | Decision | Accepted tradeoff |
|---|---|---|
| The workflow depends on changing websites, generated files, and transfers between systems. | Define verification, failure behavior, and recovery as part of each feature’s contract. | Spend more time on validation and operational behavior than the happy path alone requires. |
I defined expected behavior for repeat runs, missing inputs, invalid content, incomplete transfers, and unavailable optional data. New files are verified before replacing trusted copies. Invalid material content is rejected before rendering. Status commands report what last succeeded, what failed, and whether local information still needs to be published.
Not every failure has the same consequence. For example, a missing engagement projection produces a warning while Search continues; losing that additional context should not prevent a valid alert from being sent.
This work added implementation and testing effort, but it made the system safer to operate and easier to diagnose.
Reliability and validation matrix
8 cases exercised · 8 safeguards verified
Eight of eight exercised reliability cases passed, covering warnings, rejected stale or invalid input, idempotent reuse, guarded destructive behavior, rollback, and recovery.
| Exercised condition | Intended safe behavior | Verified result |
|---|---|---|
| Replica freshness record missing | Warn without damaging the readable replicaDegrade safely | Passed |
| Outdated match selected | Refuse the stale action; preserve the existing applicationReject safely | Passed |
| Engagement projection malformed | Omit optional annotations; preserve match identityDegrade safely | Passed |
| Returned resume material invalid | Reject it before trusted publicationReject safely | Passed |
| Same application started twice | Reuse the durable record instead of duplicating it | Passed |
| Replica publication interrupted | Restore the prior valid pair; allow a clean retryRecover safely | Passed |
| Reset target unsafe | Refuse before modifying any filesReject safely | Passed |
| PDF publication interrupted | Preserve the prior complete document bundleRecover safely | Passed |
Replica publication recovery sequence
Five-step recovery sequence showing a valid database and manifest pair, an interrupted replacement, restoration of the prior pair, and successful verified retry.
- Prior database + manifest pair is valid.
- A distinct candidate pair is staged.
- Publication is interrupted.
- The prior valid pair is restored; no partial artifacts remain.
- Retry publishes and verifies the complete candidate pair.
Review, revision, and acceptance
Automated review once found that a schema definition rejected every valid résumé-content payload. I reopened the work, corrected the contract, reran controlled validation, and accepted the workflow only after deployment testing passed.
The review found the defect; accountability required responding to it and proving that the corrected system behaved as intended.
Technical detail: Staged transfers, failure handling, and recovery
Transfers are staged before installation. Job Radar verifies the expected file, checksum, and related metadata before replacing trusted state; failed verification leaves the prior accepted copy in place. Where appropriate, rollback behavior restores the earlier artifact after an interrupted replacement.
Failure severity follows the responsibility of the affected feature. A failure that makes core Search results unsafe stops the operation. A failure in optional enrichment, such as an unavailable engagement projection, is reported without blocking an otherwise valid alert.
Validation begins in isolated scenarios with explicit data locations and expected outcomes. Successful controlled tests are followed by real-environment checks on the Mac and TrueNAS deployment. Status output makes the resulting operational state inspectable after the command completes.
AI collaboration
Expand capacity while retaining accountability
The same distinction between assistance and authority shaped how I built Job Radar. AI increased the scale and pace of work I could undertake independently; responsibility for what the system should do and whether it could be trusted remained mine.
| Activity | My responsibility | AI contribution |
|---|---|---|
| Problem and scope | Identified the need and decided what was worth solving | Helped explore implications and clarify ambiguity |
| Requirements | Defined boundaries, constraints, and acceptance criteria | Helped formalize decisions and surface missing cases |
| Architecture | Evaluated tradeoffs and accepted the final design | Proposed options and identified risks |
| Implementation | Directed bounded work and reviewed resulting behavior | Codex produced much of the code, tests, migrations, and repository changes |
| Review | Interpreted findings and decided what required correction | Codex performed automated review and identified defects |
| Validation and deployment | Designed and executed controlled and production scenarios | Helped create test plans, scripts, and diagnostic guidance |
| Acceptance and accountability | Decided whether the system could be trusted and owned its operation | Held no authority to accept the result |
The collaboration worked because responsibility remained explicit. AI could propose, implement, and critique; I remained responsible for deciding what should exist and whether the result was safe to rely on.
Process detail: Bounded implementation, review, and acceptance
- Ambiguous need
- Product and architecture decisions
- Bounded implementation brief
- Codex implementation and tests
- Automated review
- Revision and controlled validation
- Production testing
- Human acceptance
I separated architecture and product decisions from implementation tasks. Before asking Codex to change the repository, I defined the goal, current constraints, exclusions, deliverables, and completion criteria for a bounded slice of work.
Codex implemented the slice and its tests, then performed automated review. I interpreted the findings, decided which issues reopened the work, and validated the corrected behavior in isolated scenarios before moving into the real Mac or TrueNAS environment.
The loop ended with human acceptance, not code generation or a passing automated review. That distinction prevented plausible implementation output from silently becoming an approved product decision.
Operational outcome
A system I can operate and improve
Job Radar now monitors configured career sites each day, preserves posting history, evaluates potential matches, and sends alerts. On my Mac, I can carry a persisted Match ID into research, material preparation, submission tracking, and employer response, then publish only the engagement information Search needs.
The system is intentionally narrow. It serves one user, monitors a configured set of employers, and retains deliberate preparation and publication steps. It is not a public job board, a general-purpose applicant tracker, or an automatic application service.
The most important result is not the volume of work automated. It is that I can rely on the workflow because its sources of truth, decision rights, privacy boundaries, and failure behavior are explicit.
Job Radar began as a way to make my own search more manageable. Building it required me to act as product owner, systems designer, operator, and final reviewer. It demonstrates the same approach I bring to a growing SaaS team: turn ambiguity into structure, use powerful tools deliberately, and remain accountable through execution.
Start a conversation
If your team needs someone who can connect product intent, operational reality, and implementation detail—and stay involved until the system works in practice—I’d like to talk.