Replay QA

the recorded-session-to-root-cause handoff is the interesting part, most QA tools stop at "here's a broken screenshot" and this closes the loop back to something a coding agent can actually act on. one question I didn't see covered above: when the agent auto-explores an app that has real user data behind auth (not just a throwaway account), what happens to whatever it touches or records during that exploration - is there any scrubbing/redaction of sensitive fields before a recording gets stored, or is it on the team to only ever point it at a sandboxed environment?

The 'gives your coding agent the root cause and fix' part is what makes this interesting. Most QA tools stop at finding the bug and leave you to figure out why. Been burned too many times by vague error reports that take longer to investigate than the actual fix. Any plans for mobile app support? Building a Flutter app and this would be genuinely useful for catching edge cases before users hit them.

This is awesome! I'm looking forward to digging into this. Might write a forum when I do. Congrats on the launch. Nice to see @mplacona in the mix. 🤩

Congrats on the launch folks! Can’t wait to take it for a spin

Congrats on the launch! I really like that Replay doesn't stop at finding a bug, but actually captures the entire path to reproducing and fixing it. That's a much more useful artifact than just another failing test or screenshot.One thing I'm curious about: how do you measure exploration coverage? At what point does the agent decide it has explored "enough" of an application, especially for larger products with lots of user flows?Definitely worth testing !

This looks cool! How does Replay QA prioritize which bugs are worth fixing first?

How do you compare yourself to github copilot?

Is there a way to give it a test email to enter a logged-in area of our browser-based software? Without giving Github access, just to act as if it's a real user setting up an account.

Congrats on the launch. The coding agent handoff is what caught my eye. Curious what the root cause artifact actually looks like in practice: is it a structured description of the broken flow, a reproduction trace, or something closer to a prompt the agent can act on directly in Cursor or Claude? Also wondering how it handles async UI states where the same event sequence sometimes resolves and sometimes fails, since that seems to be exactly what the thread is wrestling with.

Congrats team! The “record once, reproduce forever” idea is the part QA teams dream about, half our bug reports die at “cannot reproduce.” My question is about what’s inside the recordings: when a session captures real user data, what happens to PII before a recording gets shared with the team or fed to an AI for debugging? Redaction controls would be the deciding factor for us using this on production sessions.

Hey Product Hunt,Marcos here from @Replay.Shipping apps has changed. AI coding tools make it much faster to build something that looks like it works. But the hard question hasn't changed: does this thing actually work in the browser?We built Replay QA to answer that. Give it a URL and it explores your app like a real user, then produces a structured QA report showing what broke, where it broke, and exactly what your agent or team needs to fix it. Every session is recorded with our time-travel debugger, so you can replay the exact moment a bug occurred.And if you're building something for the public - free tier included. If your app is posted to a public link (Show HN, Reddit, X, Product Hunt), you can test it for free. Create a project, set your public share link, and it becomes free immediately. Any existing credits are refunded.Give it a try: qa.replay.ioWe'll be here all day answering questions about what Replay QA checks, how the reports work, how this fits with coding agents, where it fits alongside existing testing tools, and how teams can use it before launch or in CI.Would love to hear what you think - especially if you have an app we should test.

One thing that would make Replay way more useful for me: a "diff" view that lets you replay two recordings side by side and highlight the differences. Would be huge for QA teams trying to spot what changed between a working build and a broken one.

Root-cause handoff to coding agents feels genuinely useful. How do you decide which flows Replay QA explores first?

honestly this looks pretty cool, would love to see a way to redact sensitive info like api keys or user emails before sharing a replay. kind of a blocker for shipping these to support or external devs right now.

Recording right in their browser and being able to jump through the timeline with devtools feels genuinely useful, especially when sharing a weird bug with my team.