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
"Verification is the product, the apply is just the verb" is a great reframe — and it generalizes. My version of your silent-failure gap was a metrics one: I proudly watched signups climb, but the event that actually mattered was "did the group ever do anything together," and most didn't. The signup was a filled form; the real outcome never fired, and my happy dashboard hid it. Took me way too long to move my north-star off the vanity number. When you switched to requiring 2-of-3 confirmation, did conversion look worse on paper before it got better? Honest metrics usually sting first.
honest answer: yes. the day we started counting only verified submissions, the number got visibly smaller, same pipeline, same volume. nothing changed except we stopped counting maybes. it stings exactly once, then it becomes the only number you trust. your group-activity metric is the same lesson in different clothes: the number that hurts is usually the one that's true.
Only charging for confirmed outcomes is a genuinely smart pricing model here because it turns verification from a feature into the business model itself. You're not selling automation, you're selling certainty, and certainty is worth more than speed to someone who's been burned by silent failures before.
The trust signal this sends to new users is probably more valuable than the actual verification mechanic. Most tools in this category are asking users to trust a dashboard. This one is saying the dashboard only counts things that actually happened.
one honest correction, because i'd rather disappoint you here than at a checkout: we don't bill per confirmed outcome. an attempt costs real compute whether it lands or not, so credits are spent per attempt, and the verification layer is about honest reporting, not refunds. the failed column exists so you always know which attempt was which. your trust point stands though, a dashboard that only counts what actually happened is the product.
Fair correction, and honestly the more honest model, per-attempt cost is at least legible even when you land zero results, versus a black-box success fee that's easy to mistrust. The dashboard-that-only-counts-what-happened framing is a good trust anchor. Do you show attempt cost per application inline, or does someone have to go dig for it to notice the ratio is bad?
inline, tied to each application record rather than a separate report, because a buried cost number is the same trick as a buried failure state. the ledger debits per attempt against the application itself, so a run of expensive attempts with nothing verified reads as exactly that when you scroll your own history. the principle underneath: any number that would change a user’s behavior has to live where they already look. the moment honesty requires opening an export, you have rebuilt the thing you were criticizing with one extra click.
"The moment honesty requires opening an export, you have rebuilt the thing you were criticizing with one extra click" is a genuinely good line, it nails why burying a true number is functionally the same as hiding it. Keeping the cost tied to the application record instead of a separate report respects that people won't go looking for bad news on their own. Have you seen this change actual behavior yet, or is it too early to tell if people adjust once the cost is sitting right there?
too early for a clean read on spend behavior. what did move fast is support tickets asking did it actually go through, those basically stopped, which was the original point. whether people apply differently once the number is in their face needs more than a week of data and i don't want to call it yet.
Most tools sell the vanity metric of "forms filled," not successful applications. Verifying the submission is the only feature that matters to a job seeker. You are selling peace of mind, not just automation.
'peace of mind, not just automation' is close to what users say back to us unprompted. the uncomfortable part is that peace of mind is the easiest thing in the category to fake, every tool shows a green checkmark. reading the ats's own confirmation back after the send is the unglamorous version nobody demos.
"verification is the product, the apply is just the verb" — this line is gold.
I just spent 6 days building an idea validation pipeline. The hardest part was a filter that checks if anyone is actually paying for the problem — it killed 2 of my best ideas.
Pain is easy to find. Verification is the hard part.
a filter that kills 2 of your best ideas is a filter doing its job. 'pain is easy to find, verification is the hard part' generalizes frighteningly well. curious what your is-anyone-paying check looks like in practice, that's the step most validation pipelines quietly fake.
No hierarchy when every signal is a witness to someone else system. That is the right constraint. A tiebreaker toward success would reintroduce the exact false-positive risk the verification layer exists to remove. The cost is clear: a lower reported success rate and the confidence that every counted application actually exists. Do you show users the conflict rate or just the final count?
per application we show the state on the row itself, so a user sees pending or applied or failed for each one. we do not surface an aggregate conflict rate, and you are right that it is the more interesting number.
the reason it is awkward to publish is that most disagreements are not really conflicts, they are one signal present and the others simply absent. a confirmation email arrives and nothing else does. that is not two witnesses contradicting each other, it is one witness and a lot of silence. a rate that lumped those together would mostly measure how chatty a given employer system is, not how uncertain we actually are.
the number that would be worth publishing is narrower: how often we moved a row to applied and later found evidence it never registered. that is a real error rate rather than a noise rate. we do not publish it yet, and the honest reason is that it needs a longer observation window than we currently keep per application.
The multiple-failure-modes approach makes sense. Each signal fails in a different direction, so no single one is safe. What happens when the two signals disagree in opposite directions, say the confirmation page showed success but the portal check came back empty? Do you treat that as unverified, or is there a signal hierarchy for tiebreakers?
conflict means unverified, full stop. no signal outvotes another in favor of success, because each signal's false-positive mode is exactly the case where trusting it burns you. a success-looking confirmation page with an empty portal check gets flagged, not counted. the honest bucket costs us bragging rights and buys the only thing that matters, that a counted application actually exists.
Backend truth beats frontend smoke. Conflict = unverified, period. My hierarchy: gateway callback first, then API state, then confirmation page – but in a tie, frontend is ignored. I also add a 24‑hour pending review before archiving false positives.
Do you use a strict hierarchy or do you give conflicting signals a time window to resolve?
strict on direction, loose on time: a conflict is never resolved toward success, but slow signals get a window to arrive before we finalize, some ats confirmations show up late. your gateway-callback-first hierarchy makes sense for payments where the backend is authoritative. our backend is someone else's ats, so every signal is a witness, not a judge, and we require agreement.
"Verification is the product, the apply is just the verb" is the whole business in one line. Every automation category has this split: the tool that reports the action versus the tool that proves the outcome, and only the second earns trust. I'd put that confirmed-submission number front and center in your marketing, because your whole audience got burned by tools that counted a filled form as a win, and that's the exact wound to press on.
agreed, and we're moving that number forward in the marketing. the careful part is saying 'confirmed submission' without implying anything about what happens after, interviews and replies belong to the employer and we never promise them. 'the tool that reports the action versus the tool that proves the outcome' is the cleanest phrasing of that split i've seen.
This maps directly onto something I ran into building PM OS (SOW → project
plan generator with GPT-4o) — the model would confidently return a
"complete" structured plan even when it had silently dropped or
misinterpreted parts of the source document. Looked done, wasn't actually
right. Same trust gap you're describing, just on the output side instead
of the submission side.
I ended up adding a similar idea to yours — a verification/confidence pass
that flags anything the model wasn't sure about instead of presenting
everything with equal confidence. "It ran successfully" and "it did the
right thing" turned out to be two completely different claims, and most
AI tools conflate them.
Also relevant on the other side — I actually went through a round of job
applications recently, several through auto-fill tools, and had zero
visibility into whether they'd actually landed. Would've genuinely used
something like this to confirm.
'it ran successfully' and 'it did the right thing' being two different claims is the whole bug class, yours on the output side, ours on the delivery side. the confidence-pass you added is the right instinct, uncertainty deserves to be surfaced, not averaged away. and the zero-visibility feeling you describe after auto-fill applications is the exact wound this started from.
The two-of-three quorum is the right design, and there is a second failure class worth getting ahead of: the verifier itself decays. ATS platforms redesign their confirmation pages, email templates change, portals move. When that happens, your verification layer quietly starts failing in one direction, and either "couldn't verify" creeps up or a
false-positive pattern creeps in, with no error anywhere. What has saved me repeatedly in business automation is a scheduled reconciliation pass: sample recent verified and flagged items, re-check them against the source a day later, and alert when the disagreement rate moves. The loud-vs-quiet failure asymmetry you described applies to the verification layer too, so the tripwire needs its own tripwire.
Second thing, since retries are inevitable: make each application an explicit little state machine with a dedupe key (attempted, claimed, verified, flagged) so a retry can never double-submit to the same employer. In your category a duplicate application reads as spam on the employer side, which burns the user worse than a missed one.
And on flagged-reads-as-a-bug: put the evidence next to the flag. You said you already store what the ATS returned, so show it. "Couldn't verify, here is what we saw" turns a flag from an error message into proof of diligence, which is exactly the trust you are selling.
this is the failure class that actually worries me, because it fails silently in one direction. two things help: the verifier reads the page semantically, like a human would, instead of matching a stored template, so a redesign tends to degrade into 'couldn't verify' rather than a false positive. and every couldn't-verify lands in a visible bucket we watch, so decay shows up as a creeping rate, not a surprise audit. not bulletproof, but the failure direction is at least honest.
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.
Loud failures get fixed in a day, quiet ones get discovered in an audit is the exact reason this category of bug is so dangerous. Everything looks fine until the moment it doesn't, and by then the gap between what the dashboard said and what actually happened is already months wide.
and the months-wide gap is the scary part, because every day inside it feels fine. the only fix we found is making the quiet failure loud on purpose, a visible bucket on the dashboard nobody can unsee. an audit should be a confirmation, not a discovery.
Making the quiet failure loud on purpose is the right instinct, most tools bury the thing that would actually change behavior. Curious how you decided on the visible bucket's threshold, is it time-based (X days without an update) or something tied to expected response windows for that type of application?
threshold is signal-based, not calendar-based. verification settles at submit time on the immediate signals (ats response, confirmation page state, receipt email), and two of three closes it right there. the only time dimension is the receipt email, since ats confirmation mails can lag by hours, so a submission missing just that signal sits in a short provisional window instead of getting flagged instantly. once the window closes with fewer than two signals, it goes to the visible bucket. we tried modeling expected response windows per application type early on and dropped it: response windows describe when a human replies, not whether the form landed, and mixing the two made the bucket mean nothing.
Dropping the expected-response-window model because it conflates "a human replied" with "the form landed" is the kind of mistake that looks reasonable until you actually ship it and watch it produce nonsense. Signal-based verification settling at submit time makes a lot more sense, it's measuring the thing you actually care about instead of a proxy for it. How often does something end up sitting in that short provisional window because just the receipt email is missing?
more than you'd expect. a decent chunk of ats platforms never send a receipt at all, so we treat the email as corroboration, not a requirement. the provisional window mostly holds cases where the on-page confirmation was ambiguous and nothing else has corroborated yet. when the dom signals are clean it settles immediately.
"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.
That's exactly the implication I was thinking about.
I don't think the biggest strategic decision is putting verification at the front of the pipeline.
It's the business decision that follows once verification becomes the thing every other decision depends on.
Probably too much to unpack properly in a thread.
If you're interested, what's the best email to reach you on?
[email protected] reaches me directly. and yes, 'the business decision that follows once verification is the thing everything depends on' is a better description of my last two months than anything i've written. happy to unpack it properly.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
got it, replying from that inbox now. quick note so you're not refreshing: i read these properly rather than firing back a templated line, so give me a day. thanks for actually sending it instead of letting the thread trail off.
Sounds good—I appreciate you taking the time to read it properly.
No rush at all. Looking forward to your thoughts whenever you've had a chance to go through it.