Job Application Tracker — Django REST API for the Job Search Lifecycle

Two accounts can register with the same email address

Email is how support, billing, and any future "forgot your password" flow identify an account. If two different people (or one person twice, by accident) can register with the same email, there is no way to know which account an email-based action -- a password reset, a notification, a support lookup -- is supposed to act on. This is exactly the kind of gap that looks harmless until the first support ticket titled "I reset my password but I still can't log in to MY account" shows up, because the reset silently touched the wrong one of two accounts sharing an email.

An application that received an offer can never be marked rejected

Declining an offer is one of the most common, completely normal endings to a job search -- a candidate accepts a different role, negotiates and walks away, or just changes their mind. Right now, the tracker has no legal way to record that: once an application reaches offer, it is permanently stuck there. Every user who reaches this point -- arguably the most important milestone the whole app exists to track -- hits a dead end exactly when they're closest to being done, and their application history is permanently wrong: it'll say "offer" forever even after they've told everyone they turned it down.

No way to filter the application list by status or company

The entire point of tracking applications through applied -> interview -> offer/rejected is to be able to answer "what do I need to follow up on right now?" -- which for anyone with more than a handful of applications means filtering to just the ones at a given stage, or just the ones at a specific company. Today there is no way to do that: GET /api/applications/ always returns everything, paginated 20 at a time, and a user with 60 applications has to page through all of them to find the three currently at interview. This directly limits how useful the product is to its heaviest users -- the ones actively job-searching across many companies at once, which is exactly the audience this tool is for.

Every user can read every other user's applications

An Application row contains a user's employer names, the roles they're interviewing for, and freeform private notes -- the kind of information someone very much does not want their current employer, a recruiter, or a stranger to see. Right now, any authenticated user can list every other user's applications just by calling GET /api/applications/ as themselves -- company names, roles, and notes included. This is a confidentiality breach across every account on the system, the kind of finding that turns into a mandatory disclosure, a trust-destroying incident for a tool whose entire premise is "track your confidential job search privately," and, per the project's own README (which documents user isolation as a core guarantee), a direct contradiction of a promise already made to users.

Overlapping status-change requests can silently corrupt an application's history

StatusChange is the tracker's permanent record of what happened to an application and when -- the entire value proposition of this app over a spreadsheet is "I can trust this history." apply_transition is the single code path every status change goes through specifically to guarantee that trust. But it was never hardened against two requests landing close together (a user double-clicking "reject," two browser tabs open on the same application, a retried request after a slow network) -- and when that happens, the slower request can silently overwrite a status that a faster, later, perfectly legitimate request already committed, while also permanently writing a StatusChange record describing a transition that never should have been allowed to happen. A user could end up with an application that says interview when they distinctly remember rejecting it -- and a history log that "proves" an impossible sequence of events, with no error, no warning, and nothing to grep for afterward.