Andrew Williams

I'm launching Saturday, and this product exists because of wrong numbers. Most browser-based mouse testers count one movement per displayed frame, which means they're measuring your monitor (a 1000 Hz mouse reads as 60 Hz on a 60 Hz display), printed with total confidence.
When I started measuring properly, I ended up publishing error bands instead: every number on InputProbe comes with the accuracy band it was measured to, and when a capture can't support a number, the tool refuses to print one and says why.

Before launch I'm collecting failure stories. Have you ever used an online DPI checker, polling rate tester, double-click tester, or keyboard tester and gotten a result that didn't survive a second look (a DPI that didn't match reality, a polling rate that changed between runs, a "faulty switch" verdict on a healthy mouse)? Which tool, and what did it tell you?

I'll take the failure modes people report here, reproduce them, and write up what actually causes each one.

Engineering culture says document your limitations. Marketing culture says lead with your strengths. I keep seeing evidence for both: changelogs that openly admit bugs seem to earn trust, "known limitations" pages get cited approvingly in communities (and yet the competitor with the confident, caveat-free claim often still wins the comparison table).

So I'd love real stories from builders here.

• Have you shipped something where you stated the limits up front: error margins, unsupported cases, an honest "this tool can't do X"?

• What actually happened: did users reward the honesty, or did you just hand your objections to a competitor on a plate? And the reverse: has anyone overclaimed, gotten caught, and can say what it cost?