solo founder, building in public. short writeup of the one engineering problem that became the whole product.
i built a thing that auto-applies to jobs. the easy 90% is filling the form and clicking submit. the part nobody ships is the last 10%: did the application actually land in the company's ATS, or did the page just render something that looks like success.
the failure mode that scared me is the false-positive submit. a confirmation toast or "thanks for applying" screen can render even when the backend rejected the record. required field hidden, page bounced to an aggregator, role already closed. you get a green checkmark and nothing reached the employer.
so i stopped optimizing for "we filled the form" and rebuilt around one question: did this submission actually go through.
how it verifies, the way a human would double-check:
- the post-submit confirmation state on the page
- a confirmation email landing
- the application showing up in the candidate portal
it only marks a job "submitted" when at least two of those three independent signals agree. requiring 2-of-3 killed most of the false positives.
other notes:
- it drives a real browser per application, not a background POST, because the big ATSs break the naive autofill path.
- when it gets stuck it stops and surfaces a specific reason (job closed, captcha wall, auth wall) instead of retrying forever and burning money.
what i'd genuinely like feedback on: how would you tell a real ATS write apart from a UI that just looks successful? that's the hard part and i'm sure i'm missing cases.
it's free to start if you want to poke at it: https://aiapplyd.com/?ref=devto
SOCIAL SHARE CARD GENERATOR