We built a 'failed' column on purpose, then caught our own agent triggering it
most auto-apply tools have a dirty secret: they only autofill the form. they drop your details in and stop. some press submit. almost none read the confirmation the applicant tracking system sends back afterward, which means they cannot actually tell a click from a landed application. so they show you "applied" and hope.
we read that confirmation. it is the whole point of what we build. and the side effect of reading it is that we have a status most tools do not: failed. a column that says, out loud, this one did not go through.
having that column means we can be wrong out loud too. today we were.
our apply agent clicked submit on a real Greenhouse form. the form went through. then, about half a second later, a downstream network blip threw an error, and the old code took that to mean the whole run had failed. it stamped a real, registered application as failed. a false negative on the one signal that matters most.
the fix (in submitter.ts) is a gate we now call submitClickIssued. once the agent has actually clicked submit, a later transport error can no longer produce a hard failed. it resolves to requires_human_review with a "likely landed, confirm this one" disposition instead. a blip after the click can no longer fake a failure. worst case, we ask you to double-check one, instead of lying to you in either direction.
it is not a glamorous ship. no new feature, no screenshot. but a tool that never fails is a tool that never tells you, and the boring reliability days are the actual product.
building this in public. no fabricated numbers, just the log.
This is a great example of what happens when you stop optimizing for “happy path success metrics” and start modeling real-world uncertainty. The addition of a “failed” state isn’t just a UI decision—it’s a shift from binary success reporting to truthful state representation. The interesting part is that the system became more reliable not by reducing failures, but by classifying them more honestly.
'more reliable by classifying failures honestly, not by reducing them' is exactly the counterintuitive part. reliability work usually chases the failure rate down; ours started paying off when we stopped arguing with the rate and made every failure legible instead. a correctly-labeled failure is retryable. an invisible one is permanent.
The invisible bucket is the underrated piece. Most reporting is optimized to look good, not to be useful, so the real failure rate stays hidden until someone deliberately audits it. Do you think the market eventually rewards visibility over vanity here, or is the asymmetry too embedded in how buyers evaluate tools?
i think the market rewards visibility only after someone gets burned, and unfortunately that's a renewable resource in this category. buyers evaluate on the happy-path demo, then churn on the first silent failure. so vanity wins the acquisition and visibility wins the retention. we've decided to build for the second even when it demos worse.
"Vanity wins acquisition, visibility wins retention" is worth sitting with. Most tools optimize for the first demo and call it product-market fit. Building for the second knowing it demos worse takes conviction most founders dont have. Do you find that the buyers who get burned seek you out, or do you still have to compete on the happy-path demo to get in the door?
The failed column is a smart approach. The distinction between form filled vs submit clicked vs confirmation received is one of those things that sounds obvious once you spell it out, but most tools skip it because each extra check adds surface area. The requires_human_review fallback seems like the right call. Do you find that false positives (tools claiming success when it didnt actually land) are a bigger problem in the market than the false negatives you caught here?
Both, and the split is not flattering to the idea.
People who have already been burned once do find it, and they convert on exactly that column. But they are a small population and they arrive late, usually after they have already paid for something else and watched it not work. Everyone earlier in the cycle is still comparing happy-path demos, and against that we lose, because a screenshot of a caught failure is a worse screenshot than a screenshot of a success.
So where I have landed is that the honest surface is a retention and trust asset that does close to nothing for top of funnel, and I have stopped pretending it is a hook. It belongs on the product surface, not in the headline. Pitching it as the headline was me enjoying the principle more than reading the numbers.
false positives, by a wide margin. a false negative annoys one user, who double-checks and finds the application actually landed. a false positive quietly burns weeks: you believe you're sitting in 30 pipelines while you're really in 12, and you make decisions on that fiction. the market defaults to false-positive-heavy because 'applied' is the easiest number to inflate and the hardest for a user to audit. the failed column exists to move errors from the invisible bucket to the visible one, where they're merely annoying instead of expensive.
Neither, honestly, and that is the uncomfortable part.
The burned buyer does not go looking for a tool that admits failure. They stop looking for tools. That is what being burned does. The ones who show up still arrive through the happy-path door, because that is the only door anybody knocks on, and then the honest column becomes a retention argument rather than an acquisition one.
So the demo still has to be good. The difference is what it is allowed to claim. A demo that shows the thing working is fine. A demo that shows only the thing working, with no visible state for the other outcome, is the thing that creates the next burned buyer.
Where I have actually seen it pay is the second week, not the first day. Nobody has ever chosen us because of the failed column. Several people have stayed through a bad run because of it, since a visible failure reads as a system working correctly and a silent one reads as a lie.
What I have not solved: the honest version is strictly worse at the top of the funnel and strictly better at the bottom, and I do not know how to sell the bottom to someone standing at the top. Have you found a way to make the durable thing legible before someone has been burned once?
The legibility problem is real, and I do not think you solve it at the top of the funnel. What I have seen work is letting the second week do the selling, then handing the new user a visible failure record as the reason to trust the next run. The honest surface stops being a pitch and starts being proof. Have you tried tying retention events back to the failed column, or is that the part still missing?