The tools I actually use to run 200K applications a day

People ask about my setup and expect a keyboard recommendation. This is the other kind of tools post: the ones that are actually load-bearing in a system that submits 200,000+ job applications a day across twenty-five platforms that don't want to be automated.

Grouped by what they're for.

Reverse engineering: Kampala

This is the tool that turns the method I described into something repeatable.

Kampala is an HTTP capture-and-replay tool. You run a real submission through a proxy, it records every request and response, and then it lets you turn that captured traffic into a flow — a reusable blueprint you can parameterise and re-run.

The part that saves days: auto-binding. Point it at a captured session in execution order and it detects data dependencies on its own — any value of eight-plus characters that shows up in a response and then in a later request gets wired as a binding. Session tokens, application IDs, CSRF tokens. Then you look at the flow graph, find the steps with no incoming edges that clearly should depend on something, and wire those by hand.

After that:

• promote_to_input on the values that vary per user — the résumé, the answers, the job URL
• extractors on the responses you'll need downstream
• pagination and for-each on the steps that need them
• run it, break it, run it again

What used to be a notebook full of curl commands and a lot of guessing is now a graph I can read. When a platform changes, I diff the new capture against the old flow and the broken binding is usually obvious.

Coding: Conductor + Claude Code

Most of the backend work now happens as several parallel coding agents, each in its own git worktree, each on its own problem.

Conductor is the Mac app that runs them side by side. One workspace is fixing a Greenhouse integration, another is writing the postmortem, a third is touching the mobile app — each with its own branch, its own checkout, no stepping on each other. I review diffs, I direct, I take over when it's faster to type than to explain.

Claude Code is what runs inside each workspace. It's the first agent I've used that's good at reading a codebase before changing it — tracing the real flow through the callers, then making the small change in the right place rather than the small change in the place the ticket named. For a system with twenty-five integrations that all route through shared workers, that difference is the whole game.

I'm not going to pretend this is magic. It's a very fast junior engineer who never gets tired and needs to be told what "done" means. The leverage is real if you're specific.

Runtime: Node, BullMQ, Redis, PostgreSQL

The workers are Node and TypeScript. Every ATS platform gets its own BullMQ queue on Redis, its own concurrency limit, its own retry schedule — so one platform's bad day is quarantined by construction.

PostgreSQL holds everything durable: applications, their full request/response traces, user profiles. Neon for the database itself — branching a copy of production to test a migration against real data has saved me from at least two bad Fridays.

Playwright for the on-device flows, where the user watches every field fill and can stop it mid-submission. Server-side, we don't drive a browser at all where we can avoid it; the replayed flows hit the endpoints directly and are an order of magnitude cheaper.

Observability: PostHog + Datadog

You cannot run twenty-five things you don't control without knowing, per platform, per hour, what the success rate is.

Datadog is the infrastructure side: per-queue throughput, latency, error rate, and the alerts that pause a platform automatically when its failure rate crosses a threshold. PostHog is the product side: what users actually did, session replays when someone reports the autofill missed a field, and the error tracking that groups a new ATS-side change into one issue instead of four hundred.

Between the two, a 2am page comes with the trace attached. The fix starts from evidence.

Work: Linear

Issues, projects, the small amount of process a five-person team needs. What I like is that it stays out of the way — I can file an issue from the terminal mid-investigation and get back to the investigation.

What's not on this list

No editor evangelism. No terminal theme. No mechanical keyboard review. Those are preferences, and they're not what makes the system run.

The pattern across everything that is here: capture the truth, isolate the failure, make fixing it boring. Kampala captures the truth about how a platform actually works. Queues isolate the failure. Observability makes the fix start from evidence. The coding agents just make all of it faster.

That's the setup.