Four things that cost us money while automating job applications

Ava Bagherzadeh — Tue, 22 Sep 2026 14:52:46 +0000

Filling a job application is a browser-automation problem that looks solved and is not.

We run an MCP server that applies to jobs end to end on the employer's own hiring system. Fifteen applicant tracking systems: Greenhouse, Lever, Ashby, Workday, iCIMS, Personio, Teamtailor, SmartRecruiters, Recruitee, Breezy, Workable, Rippling, BambooHR, JazzHR and softgarden. Here are four things that cost us real money to learn.

1. Scoring on your own input is not evidence

The first version reported success when the upload call returned staged: true and the field read back files: 1. Both were true. Zero bytes reached the server.

The automation library took a different code path on a remote browser and sent nothing, while every counter we owned said it had worked. We were reading our own writes back and calling it proof.

The rule we run on now: never score on a read-back of your own input. Only score on something the other side produced. A request on the wire. A confirmation page. An email from the employer. submitted: true is a variable you set. It is not a receipt.

This generalises well past job forms. If your integration test asserts on state your own code wrote, it asserts nothing.

2. An empty result is not a zero until you prove you were watching

We spent 23 debugging sessions reading logs that showed nothing wrong. Nothing was wrong in the logs. The instrument started 18 seconds after the event it was supposed to measure, so a working fix and a total failure produced identical output: silence.

Before you believe any empty list, prove three things:

The instrument was armed at all, at the right scope.
It was armed before the event and still armed after.
The mechanism works when a human does it. Then diff the human run against yours. The divergence is the bug.

If you cannot prove all three, the correct word is not "absent". It is unobserved. Write that down instead, and go fix the instrument before you touch the subject.

We found the upload bug in minutes once we stopped reading logs and opened the page in a real browser.

3. HTTP 200 is not success, and a 200 from an SPA is not even a page

Two separate versions of this one bit us.

A provider returning an overloaded-service message inside the body of a 200 made our SDK classify it as a schema validation failure. We spent a day looking for drift in a parser that was fine. Match the error text, not the status code.

Separately, while surveying sites this week, several returned 200 for /submit, /add-tool, /new and four other paths that do not exist. They are single-page apps with a catch-all route. A 200 there proves the server answered. It says nothing about whether the page exists. Read the body.

4. A list that is still rendering is not a list

Dropdowns were harvesting exactly one option. The code waited for a loading placeholder to disappear, which it did, correctly, while the list kept painting rows behind it.

Waiting for the absence of a spinner is not the same as waiting for the presence of the data. We now settle on count stability: read the option count, wait, read it again, and only proceed when it stops changing. One field went from 1 option to 7.

The part that has no clever fix

The distinction we built the product around is that an application is not "sent" because we clicked submit. It is sent when the employer's system says it received it. Those are different events and only one of them is checkable.

Most of the engineering above exists to keep that honest, because the tempting version, where your own click counts as the outcome, is much easier to build and quietly useless to the person waiting for an interview.

The MCP server is public and works in Claude, ChatGPT and Cursor over streamable HTTP at https://mcp.aiapplyd.com/mcp. Source mirror: github.com/aiapplyd/aiapplyd-mcp. The product is AI Applyd.