I built an auto-apply tool, then found out a lot of "applications" never actually submit
quick build-in-public update, solo founder, no team.
backstory: i built a thing that auto-applies to jobs. felt great. then i started checking the receipts and noticed something uncomfortable. a chunk of "applied" jobs had no confirmation on the other end. the form filled, the button got clicked, nothing landed. the tool reported success. the job never got it.
filling boxes is easy. actually landing in the employer's system is the hard 10%. so i rebuilt the whole thing around one question: did this submission actually go through. now every auto-apply runs a verification pass and only calls it done when it can confirm (a confirmation page, a confirmation email, or the application showing in the candidate portal, two of three or it flags it). if it can't confirm, it says so instead of lying to you.
what i learned: the trust gap in this category is enormous because the audience has been burned by tools that count a filled form as a win. verification is the product, the apply is just the verb.
if you've used any auto-apply tool and felt unsure whether it really submitted, that feeling is the exact thing i'm building against. did you ever confirm one of those actually went through? how?
it's free to start if you want to poke at it: https://aiapplyd.com/?ref=indiehackers
This is the part most tools miss. I'd rather see "submission couldn't be verified" than a fake success—it saves time and builds real trust.
same conclusion i landed on. an honest 'couldn't verify' costs a little trust upfront and saves all of it later. the awkward part turned out to be ux: a flagged application reads as a bug to some users even when it's the tool doing exactly its job. still better than the alternative.
Organizations are now screening against bot or automated applications. To filter interested candidates there are various screening mechanisms created. This could challenge your idea.
true, and honestly fair from the employer side. the way i square it: screening exists to filter low-effort spray. what i build drives the same real ats form a person would fill, with the user's real resume and real answers, one application at a time, then reads back what the ats returned. the thing i'm fighting isn't screening, it's tools that never confirm anything landed. if anything, stricter screening makes verification more necessary, not less.
Verification is the product is a reframe that probably applies to most automation tools in categories where the action happens on someone else's system. If you can't confirm the outcome independently, you're just automating the hope that it worked.
Discovering this by watching silent failures accumulate rather than a single loud one is both the worst and most honest way to find it. The applications looked like they went through, which is exactly what makes this kind of bug invisible until someone specifically goes looking for it.
'automating the hope that it worked' is a better one-liner for this than anything i've managed to write about my own product. and yes, the silent accumulation was the worst part. no error spike, no crash, just a slowly widening gap between what the dashboard claimed and what employers actually received. loud failures get fixed in a day. quiet ones get discovered in an audit.
"Verification is the product, the apply is just the verb" is the whole positioning, and it generalizes: every automation category quietly counts the easy metric (form filled) instead of the true outcome (application landed). Your real competitor isn't other auto-apply tools, it's the distrust they created, so I'd make the confirmation the billable unit and the public proof at once: only charge for confirmed submissions and show the receipts. In a category full of tools that lie, being the one that says "this didn't go through" out loud is the moat, not a limitation.
the receipts half already exists: every application stores what the ats actually returned, so there's evidence to look at instead of just a checkmark. on making confirmation the billable unit, i'm deliberately slower. promising outcome-based pricing before verification is bulletproof on every ats would repeat the category's original sin, overselling. but as pressure on myself, agreed, the money should sit as close to the confirmed thing as possible.
Verification is the whole point here. A lot of workflow tools quietly define success too early, so the user gets the feeling of automation without the result they thought they were buying. I ran into the same thing with DictaFlow: speech to text is easy to demo, but if the text doesn't land cleanly in the actual field where you're working, the product failed even if the transcript was perfect. "Verification is the product" is a much stronger frame than "auto-apply faster."
the dictaflow example is the same bug wearing a different suit: perfect transcript, text never lands in the field, user gets nothing while every internal metric says success. 'where does the user actually collect the value' turns out to be the only definition of done that survives contact with production. everything upstream of that point is just activity.
The gap between 'form filled' and 'actually submitted' is the exact same pattern we see in business automation. Most tools report success on action completion, not outcome confirmation. That distinction separates tools that give you peace of mind from tools that give you a false sense of activity. Did you find the two-of-three verification threshold through testing, or was there a specific failure that revealed that balance?
it came from the failure modes of the individual signals rather than one dramatic incident. each signal lies in its own way: a thank-you page can render even when the application didn't persist, a confirmation email can lag or never come from some systems, and a candidate portal doesn't exist everywhere. any single witness gets things wrong in one direction or the other, so the rule became: no single witness decides. two independent signals kills most of the false positives without flagging every application where one signal is just structurally unavailable.
This is a subtle but important shift. Most tools in this space optimize for “task completion,” but the real user expectation is outcome completion. If “submitted” doesn’t reliably mean “received,” then everything built on top of that assumption breaks. Verification as the core feature is actually a much stronger positioning than automation.
yes, and the uncomfortable corollary: if 'submitted' can't be trusted, every metric downstream of it inherits the lie. response rate, interview rate, all of it is computed on a denominator that was never real. that's why verification moved to the front of the pipeline for me instead of living in reporting.