Hey HN, I wanted to show you a product a small team and I have been working on for 4 years.<p>It’s called Jam (jam.dev) and it prevents product managers (like I used to be) from being able to create completely vague and un-reproducible bug tickets (like I used to create).<p>It’s actually really hard as a non-engineer to file useful bug tickets for engineers. I used to write in the ticket that something didn’t work— only to lead to a ton of confusion by the engineer what I meant by “didn’t work”. Was the button unresponsive? Did the page crash? Did it return an error? Or like sometimes I thought I included a screenshot, but the important information the engineer needed was what was actually right outside the boundary of the screenshot I took. So the engineer would be frustrated, I would be frustrated, and fixing stuff would slow to a halt while we went back and forth to clarify how to repro the issue over async Jira comments.<p>It’s actually pretty crazy that while so much has progressed in how we develop software (heck, we have types in javascript now* it’s a brand new world), the way we capture and report bugs is just as manual and lossy as it was in the 1990’s. We can run assembly in the browser but there’s still no tooling to help a non-engineer show a bug to an engineer productively. It’s still a totally human driven communication process that would be better with tools to bridge the gap.<p>So that’s what Jam is. Dev tools + video in a link. It’s like a shareable HAR file synced to a video recording of the session, if you’re familiar. And besides video, you can use it to share an instant replay of a bug that just happened — basically a 30 second playback of the DOM as a video.<p>We’ve spent a lot of time adding in a ton of niceties, like Jam writes automatic repro steps for you, and Jam’s dev tools use the same keyboard shortcuts you’re used to in Chrome dev tools, and our team’s personal favorite: Jam parses GraphQL responses and pulls out mutation names and errors (which is important because GraphQL uses one endpoint for all requests and always returns a 200, meaning you usually have to sift through every GraphQL request when debugging to find the one you’re looking for)<p>We’re now 2 years in to the product being live and people have used Jam to fix more than 2 million bugs - which makes me so happy - but there’s still a ton to do. I wanted to open up for discussion here and get your feedback and opinions how can we make it even more valuable for you debugging?<p>Jam is free to use forever — there is a paid tier for features real companies would need, but we’re keeping a large free plan forever. We learned to build products at Cloudflare and free tier is in our ethos, both my co-founder and I and about half the team is ex-Cloudflare) and what we loved there is how much great feedback we’d get because the product was mostly free to use. We definitely want to keep that going at Jam.<p>The worst part of the engineering job is debugging and not even being able to repro the issue, it’s not even really engineering, it’s just a communication gap, one that we should be able to solve with tools. So yeah excited to get your feedback and hear your thoughts how we can make debugging just a little less frustrating.<p>By the way, we’re hiring engineers and if this is a problem that excites you, we’d love to chat: jam.dev/careers<p>*engineers I work with are telling me that some of you are going to argue that types don’t exist in real javascript and that web assembly isn’t assembly