I built ReproLens to explain what happened after a browser interaction — looking for testers
I’ve been building ReproLens because browser bug reports often stop at “I clicked this and it broke.” The useful clues are scattered across event handlers, Network, Console, navigation, and visible page changes, and it takes time to connect them.
ReproLens is a local-first Chrome extension. You select an element, record one interaction or a short journey, and it creates:
- A plain-language explanation of what happened
- A technical timeline with evidence and confidence labels
- A privacy-reviewed bug report
- A Playwright test skeleton
It’s now in public beta. I’m not looking for compliments — I want to learn where the explanation feels useful, confusing, or more confident than the evidence supports.
The first test takes about 10 minutes:
- Install the unpacked extension from the release ZIP.
- Run the included successful-request demo.
- Optionally try the deliberate failed-request demo.
- Tell me where you hesitated or stopped trusting the explanation.
Quick test: https://github.com/J-Jessen/reprolens-chrome-extension/blob/main/QUICK_TEST.md
I’d especially value answers to these questions:
- Was installation clear without extra help?
- Was the explanation easier to follow than checking the same interaction in DevTools?
- Did the confidence labels make the evidence feel trustworthy?
- Would the generated bug report or Playwright test save you time?
There is no signup, backend, analytics, or automatic upload. Please use only the supplied demo or a local/staging site you are authorized to inspect — never production or customer data.
I’m also happy to exchange a focused test of your product.
This is exactly the kind of problem we ran into. Connecting what a user did to what the browser actually did is the hardest part of debugging. We built around the idea of letting an assistant drive the signed-in browser so the agent sees the same state the user sees, instead of replaying a synthetic session. The trust part is the real challenge — the moment an explanation is more confident than the evidence, people stop believing it. How are you handling that confidence gap?
That confidence gap is exactly what I’m trying to make visible. ReproLens separates evidence that is directly connected to the interaction from events that were only observed shortly afterward. Each part is labelled accordingly, and it avoids claiming causality when it only has timing-based correlation.
For example, it can confidently identify an exact request, response status, handler, or source location when Chrome provides that evidence. If the connection is weaker or something is missing, the explanation should say so explicitly instead of guessing.
The next test is whether first-time users actually understand and trust those distinctions — labels alone don’t guarantee that. Since you’ve worked on a similar problem, I’d be interested to hear which confidence cues worked best for your users.
The trust question seems like the best test here. I’d watch where a first-time tester stops and whether the confidence label explains what is known versus inferred. A tiny before/after prompt after the successful and failed demos could show whether the report saves time or just adds another artifact. I’d also track installation friction separately from explanation quality so the two signals don’t blur together.
That’s a really useful distinction. Right now the quick test mixes installation, understanding, and trust into one journey, so I’m going to measure them separately. I also like the before-and-after idea: ask what the tester thinks happened before seeing the trace, then ask again after reading the explanation. That should help reveal whether ReproLens actually improves their understanding or simply produces another polished-looking artifact. Thanks — this gives me a much better test structure.
The generated timeline is useful in theory, but the real test seems to be time saved. Do testers solve bugs faster with ReproLens than with DevTools alone, or is the explanation mainly easier to read?
Exactly. I don’t have enough independent tester data yet to claim that ReproLens makes debugging faster. Easier-to-read explanations are useful, but they probably aren’t enough to justify the product on their own. I’m planning a comparison where testers investigate similar bugs with DevTools and ReproLens, then compare time to the correct cause and time to a usable bug report. That should give me a much more honest answer than simply asking which experience they preferred.
That comparison should give you a much cleaner signal. If you’re open to it, what’s the best email to reach you on?
Absolutely — the best email to reach me on is CPHAutomations@gmail.com. Happy to continue the conversation there, and thanks again for the thoughtful feedback!
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.