Readit News logoReadit News
Posted by u/thedg 2 years ago
Show HN: A web debugger an ex-Cloudflare team has been working on for 4 years
Hey HN, I wanted to show you a product a small team and I have been working on for 4 years. https://jam.dev

It’s called Jam and it prevents product managers (like I used to be) from being able to create vague and un-reproducible bug tickets (like I used to create).

It’s actually really hard as a non-engineer to file useful bug tickets for engineers. 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. Or I'd write that something "didn't work" but the engineer wasn't sure if I meant that it returned an error or if it was unresponsive. 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.

It’s actually pretty crazy that while so much has changed in how we develop software (heck, we have types in javascript now*), 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.

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. 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.

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)

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?

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.

(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.)

By the way, we’re hiring engineers and if this is a problem that excites you, we’d love to chat: jam.dev/careers

gkiely · 2 years ago
Nice work, looks like you've got some big names using it too, congrats.

I have some feedback on your homepage & messaging.

Initially scrolling the home page I thought it was a tool for viewing customer bug sessions, similar to TrackJS or Sentry.

Reading this post it became clear this is for product managers and/or team members to file bugs. The line "Built for everyone" on the home page threw me off.

I think if you make the distinction that this is an internal tool for teams vs. an external tool for tracking customer issues it might help make this messaging clearer.

I'm not sure of your plans (perhaps you also intend for external users to use it) this was just my first pass impression.

I think this is a great tool. The structured format combined with the information provided by the extension are what make it valuable to me. The last minute feature is also nice as re-creating bugs can be a PITA.

As a dev, I would ideally also want to be able to view stack traces with source maps, but having a consistent structured format combined with the extension data is enough of a value prop to start using it.

thedg · 2 years ago
I agree with your comment on messaging, that is fantastic feedback–– reading through the comments here in the HN thread, it seems like that's a common understanding from our landing page. I appreciate you flagging that, we should find better wording to make it more clear.

And that's really nice to hear, thank you so much! Stack traces with source maps. I agree. We integrate now with logging tools like Sentry and I wonder if we can just use sourcemaps from that.

FloorEgg · 2 years ago
Built for product managers who want quick bug fixes and engineers who want clear and reproducible bug reports.

It's NOT built for everyone.

Right?

asaddhamani · 2 years ago
I got the same impression at first. Then I saw the drawing tools and I thought that’s a lot to ask from end users. Messaging is confusing for sure.
alt227 · 2 years ago
I got really excited before I saw there was no firefox support. Thats a deal breaker for my team :(

I really like this idea and if Firefox support was added I would purchase it in a heartbeat.

toekneestuck · 2 years ago
[I work at Jam] We do have an internal build for Firefox.. it's coming :)
Yeroc · 2 years ago
It would be great to have a FAQ page on your site mentioning this. I was on your docs page and did a search for "firefox" as well as "safari" in the search box and there were no hits at all. Seems like something that people would often be checking for.
alt227 · 2 years ago
Awesome, I will check back regularly.

This looks like one of those tools that is genuinely really useful. I would love be able to tell my users to just fireup a browser extension and record a bug, rather than having to step them through how to capture all that data manually.

Well Done!

Bookmarking this page for the futuere: https://jam.dev/docs/downloads-and-browsers/browser-support

mattl · 2 years ago
How about Safari? This would be very useful as not every developer has Apple hardware
irrational · 2 years ago
That’s good to hear. I haven’t used Chrome since Firebug was released.
teaearlgraycold · 2 years ago
Professionally I do all of my development in Firefox and only occasionally check that Chrome works
chilling · 2 years ago
It seems pretty bold move when you consider that V8-based browsers covers 75.5% of the market [1].

[1]: https://gs.statcounter.com/browser-market-share

TacticalCoder · 2 years ago
> but the important information the engineer needed was what was actually right outside the boundary of the screenshot I took

Ah ah. At one gig we had trained the users to always send a screenshot of the entire screen. People reviewing the tickets would dump them if the screenshot was cropped and the user warned: "No full screenshot, no ticket".

Why? The most important info was the time at which the error happened (which, for users who were on Windows, was in the bottom right of the screen).

With the time we could look in the logs and the error/bug was usually obvious.

VoidWhisperer · 2 years ago
This seems like it would only work if the applications in question didn't contain any PII - as soon as you get into applications or flows within an application that contain some form of PII, either displayed or the user entering it, having them send a screenshot of the entire screen is asking for the user to accidentally leak their PII to the person reviewing the ticket.

Where I work (in which the above would be a problem), we make sure to log enough information that given a relative timeframe of when the user had the issue, we can usually narrow down to where the issue was using context and some querying of the logs (splunk is incredibly helpful for this)

freedomben · 2 years ago
Indeed, that's a great rule. Another one is "What URL was the browser on?" which is rarely ever in cropped screenshots but is visible in full screenshot
mattl · 2 years ago
Don’t many browsers hide the full URL now?
thedg · 2 years ago
URL, totally. I was talking to a PM recently where their customers self-host their product so without knowing the url, they have no idea where on the internet to start looking for the bug.
magicalhippo · 2 years ago
For us it's not the time but the id of the thing they're working on, but users tend to like to crop to just the dialog or subsection they're having issues with.

It's infinitely easier to help the customer when we can take our own look at things.

Good tip, will pass it along to support and see what they say.

stevage · 2 years ago
Seems nice but I hate sharing my whole browser window with anyone. I don't care to let other people see which plugins I use or my bookmarks toolbar etc.
EMM_386 · 2 years ago
> Why? The most important info was the time at which the error happened (which, for users who were on Windows, was in the bottom right of the screen).

Except it isn't in UTC and it doesn't show an offset.

Even if you stored the user's timezone, that doesn't mean that's where they were working from.

jojohohanon · 2 years ago
oooh. you got them. Like figuring out which timezone the user was in is impossible. What if the user intentionally set their clock wrong to mess with support.

You are being silly.

ale42 · 2 years ago
Or, some users might have hidden the taskbar, or the clock. Or have several screens, and only one of them has the clock...
williamdclt · 2 years ago
The user not being in the time zone we expected has been exactly the information we were missing to debug something more than once. “The logs say it was 10am but the screenshot says 11… what if we were mishandling timezones?”
thedg · 2 years ago
Ha! Right, totally!

That’s a great trick to get the exact time from full screenshot

JacobCarlborg · 2 years ago
Had a quick look. Seems like an interesting tool. I know there are many companies in Europe that, for regulations and compliance reasons, cannot have their data leave Europe. As far as I can see from the documentation, the data is stored in the US. Would be nice to have an option to store the data in Europe. Or not having to upload any data at all. But instead have the option export an artifact that can be processed later. But perhaps that defeats the business.
orliesaurus · 2 years ago
I am building a version of this that lets you store the data on your computer, you can export it and send it to your team (manually) so you can use any data hosting you want. Let me know if you're interested!
tetha · 2 years ago
I'd also be interested, at least for internal bug reports and such. From what I can see, jam.dev is collecting what I collect for dev-teams anyhow, just faster and more comprehensive.

But this would possibly move customer data in requests and screenshots out of our control, and the entire hassle of adding subcontractors and managing order data processing agreements have taken quite a few good monitoring and debugging tools out of discussions, sadly.

sesm · 2 years ago
From https://jam.dev/docs:

Jam is a browser extension that allows you to create the perfect bug report in just one click. You will now be able to capture an instant replay of the bug happening on your web app and include all the developer logs required to cut your bug reporting time by 20x.

(to me that was a more useful summary)

bosky101 · 2 years ago
Thanks this wasnt clear after visiting their homepage
duxup · 2 years ago
JUST in time for me man thank you. I'm going to try it.

Our company has just grown to where it isn't just some engineers and a few sales guys. Now we're trying to keep engineers working efficiently. / accurately, and the support team is ramping up. Making it easy for the sales or support guys to log a good ticket or bug is a never ending challenge. This looks like a great option.

I worked in support for ages and later moved to an engineering role, it's a mountain to climb to get good communication / reproducing things accurately enough for the engineers to really take action effectively.

thedg · 2 years ago
That is really awesome to hear. Thank you for such a nice message!

+1 –– when I worked at Cloudflare, the support team had to teach all of us how to export HAR files from our browsers for engineers. It's definitely a mountain to climb to get good bug reporting working internally.

Deleted Comment

franze · 2 years ago
Landingpage tip: Show your real product at least once, in a screenshot, in a video. Currently all images, videos are stylized which makes me think you are hidding something or at least I do not know what I will get.
thedg · 2 years ago
That's good feedback!
Corrado · 2 years ago
I love the look of this tool and will be recommending our QA team take a look. However, I would like to encourage you to make SSO free and available to everyone. Better security should be a focus for everyone, not just those on an "Enterprise" plan. Tailscale recently had a great blog post about their SSO tax journey[0]. Please don't get added to the SSO Wall Of Shame[1].

[0] https://tailscale.com/blog/sso-tax-cut

[1] https://sso.tax/

thedg · 2 years ago
Great feedback, thank you!

Our philosophy on pricing is to try and only make what real companies who can pay need, and offer what individuals and hobbyists and small startups need for for free, so that’s why SSO ended up a paid feature. But it’s great feedback for us - thank you!

saulrh · 2 years ago
The benefits of SSO kick in way faster than you'd think, in some cases before you even have a company, much less revenue. I could easily see a Hackerspace wanting SSO, for example, and adding an SSO tax of fifty dollars a month would double membership costs. Then there's stuff like https://twitter.com/NireBryce/status/1564100084652036096.