ReplayFlow 1.0 is out. Here's the honest story of why we built it and what decisions shaped the product you're looking at today.
The problem
Screen recordings for QA have been an afterthought for a long time. The workflow most teams use looks something like this: open QuickTime or the built-in recorder, capture a video, export it, compress it so it fits in Jira, attach it to the ticket, and hope the developer actually watches it.
That's a lot of friction for something that should be fast. And the recording itself usually isn't very useful — no annotations, no way to point at the specific moment that matters, and a file that sits in a ticket with zero context about what the QA engineer expected to happen.
Developers end up watching the whole video trying to figure out what the bug is. Or they don't watch it at all. Either way, someone sends a follow-up message.
What we tried first
We looked at the tools already on the market. Loom is excellent for async communication — walkthroughs, demos, team updates. But it's built for a social context, not for bug reports. The sharing flow assumes you're sending a message to a person, not attaching evidence to a ticket.
OBS is powerful but genuinely overkill. It's a professional streaming and recording suite. Configuring it to capture a single window, output a small file, and add an annotation requires more setup than most QA workflows can absorb.
Built-in system recorders (QuickTime, Xbox Game Bar, Snipping Tool) get you a file, nothing more. No annotations, no sharing, no way to make the recording useful before it lands in a ticket.
What we built
ReplayFlow is a screen recorder built specifically for the moment a QA engineer finds a bug and needs to document it. That constraint shaped every product decision.
The recorder starts fast — no project setup, no mode selection, just start recording the thing that broke. When you stop, you get a lightweight editor to add annotations: arrows, highlights, text labels at specific timestamps. Then you export or share — a short link or a compact file that doesn't require a compression step before it fits in a ticket.
We made three deliberate calls that are worth explaining:
- No account needed to view.When a QA engineer shares a recording with a developer, the developer shouldn't have to sign up for anything. A link that opens immediately, with no gate, means the recording actually gets watched.
- Timestamped annotations.The annotation you add isn't just a drawing — it's attached to a moment in the video. The developer can jump directly to the frame you flagged without scrubbing.
- Small file sizes by default. QA teams share recordings constantly. If every file is 200MB, sharing becomes a problem. We optimized the export pipeline to produce files that are small enough to attach to any issue tracker without a separate compression step.
What we learned building it
The hardest part wasn't the recorder. It was figuring out what to leave out. Every feature you add to a tool that's supposed to be fast makes it slower. We cut a lot of things we initially thought were necessary — editing timelines, team workspaces, automatic captions — because none of them solved the core problem faster than a simpler version of the tool did.
We also learned that QA engineers have strong opinions about their tools. The feedback we got during the beta was specific and actionable in a way that's rare. That made the product significantly better than what we shipped in the first private build.
What's next
1.0 is the foundation. The things we're thinking about for the next cycle: deeper integrations with issue trackers (so a recording can go from ReplayFlow directly to a Jira or Linear ticket in one step), smarter replay features that highlight the annotated moments automatically, and a Mac client alongside the Windows app.
If you're using ReplayFlow and have feedback, we want to hear it. The best way to reach us is the feedback form in the app — we read every submission.