Building an auto-apply tool

Searching and scoring are read-only: get them wrong and you waste compute. Submission writes to somebody else’s system, under your user’s name, permanently. There is no rollback and no way to explain the mistake to the reviewer who will see it.

That single property should shape every design decision. Auto-apply is closer to a payments integration than to a scraper, and it deserves the same paranoia.

The asymmetry runs through everything. A failed search costs a retry; a wrong submission costs a candidate an opportunity at a company they may care about, and no amount of later correctness recovers it.

The failure that defines this domain: a submission times out, the job retries, and the employer receives two applications from the same person. It looks careless at best and automated at worst, and it is the single most damaging bug available.

Every application needs a key — candidate plus job, deduplicated across sources — checked before submission and recorded atomically with the attempt. If the process dies between submitting and recording, on restart you must be able to tell whether it went through, which usually means an idempotency record written *before* the attempt and updated after.

Deriving the key is where this gets subtle. The same role arrives through four sources with four URLs, so keying on the posting link produces four keys and defeats the whole mechanism — the key has to come from employer plus normalised role plus candidate.

• A unique key per candidate-job pair, resolved across duplicate postings
• Written before the attempt, not after, so a crash is recoverable
• A reconciliation pass for records stuck in "attempted, unknown"
• A hard cap per employer per day, whatever the queue says

Submitting in a loop as fast as the code allows is how accounts get blocked and how a bug turns into fifty bad applications before anyone notices. Applications belong in a queue with deliberate pacing.

Rate limit per employer and per applicant tracking system, not just globally. Twenty applications to one company in a minute is a pattern that gets noticed, and it harms the candidate more than any efficiency gain is worth.

Nothing about this workload benefits from speed. An application submitted twenty minutes later is worth the same as one submitted now, so pacing costs nothing real and removes an entire category of risk — which is an unusually good trade and one teams still argue about.

A form submission has many ways to half-succeed: the CV uploads but the cover letter does not, a required field appears only after another is filled, the session expires mid-flow, a confirmation page never loads.

Decide in advance what each partial state means and record it honestly. The worst outcome is a system that reports success because it did not receive an error, leaving the candidate believing they applied when nothing arrived.

Require positive evidence of submission rather than an absence of errors. A confirmation element, a redirect to a known success page, or the application appearing in the portal’s own list — and anything short of that is recorded as unknown and resolved later, not as success.

Store exactly what was sent: the resolved field values, the file that was uploaded, a screenshot of the final state, and the timestamp. Not a summary — the actual content.

Two reasons. The candidate will be asked about this application in an interview and needs to know what they claimed. And when something goes wrong, the only way to tell a tool bug from an employer form change is to see what was actually submitted.

Give the trail a retention policy of its own, because it holds a complete copy of someone’s application materials and a screenshot of a page containing their personal details. It deserves the same scoping and deletion guarantees as the primary record rather than becoming an unexamined archive.

Build a circuit breaker before you need one. If the failure rate across recent submissions crosses a threshold, stop everything and alert rather than continuing — because a form change usually breaks every submission the same way, and the difference between noticing at three and at three hundred is entirely how fast you stop.

Add a dry-run mode that performs every step except the final click and stores the result. It is the only way to test changes safely, and you will use it constantly.

A user-facing stop matters as much as an internal one. A candidate who realises something is wrong should be able to halt everything in one action without contacting support, and the same mechanism is what you will reach for during an incident.

Treat the caps as permanent rather than as defaults to be raised. A per-day, per-employer and per-week limit that survives a user asking for more is what keeps a bug proportional, and the request to remove it is exactly the moment it is doing its job.