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