Bug-reporting tools aren’t new.
Tools like Jam.dev already capture screen recordings and technical context. So the interesting question isn’t “How do we add a recording to a bug report?”
It’s: what still makes a bug hard to reproduce, even when you have that context?
A recording can show what someone clicked. But the issue might depend on their account state, the data they were viewing, timing, or something else that’s hard to recreate. And capturing more information isn’t always the answer either: too much noise makes the useful details harder to find, while collecting sensitive data creates its own problems.
A useful report still needs to make a few things clear:
- Where did it happen?
- What steps led to it?
- What did the person expect to happen?
- What happened instead?
- Can someone else reproduce it?
The tricky part is getting that context without making the person reporting the bug fill out a long form or become a detective.
If you use Jam.dev, Marker.io, or something similar: what still sends you back to Slack to ask for more context? And what information would you not want a tool to capture automatically?
I’m exploring this space while building caes.dev. It’s early, and I don’t have a demo ready yet. The waitlist is at https://caes.dev.
Top comments (1)
More context isn’t always better if it just adds noise. I’m curious which details actually help you reproduce a bug, and which ones you end up ignoring.