Announcing the Replayable Bug Bash program!

Are you frustrated by the quality of your product? Maybe you’ve heard about bugs from your team members, but they can’t be reproduced. You’re pretty sure things aren’t working correctly, but developers say, “It works on my machine.” Your day is filled with meetings clarifying requirements and ensuring bugs marked as fixed are actually fixed.

Software developers spend 35-50 percent of their time validating and debugging software.

The debugging mindset

Between local, staging, and remote environments, split tests, feature flags, and—worst of all—caching, it can be impossible to reproduce many bugs. You can’t peer over the shoulder of your remote employees. Your less-technical team members don’t know how to “speak developer,” and your technical team members don’t want to spend valuable time repeatedly trying to reproduce bugs.

Squash the bugs!

It’s essential to find and fix bugs quickly. The longer a bug exists in your product, the more expensive it is to fix later. However, developers report spending more than 50% of their time testing1 and are consistently under pressure to ship features.

The cost of debugging, testing, and verification is estimated to account for 50-75 percent of the total budget of software development projects, amounting to more than $100 billion annually.


This is why we’re excited to launch the Replayable Bug Bash program. Replayable is a desktop screen recorder that makes it easy for your entire team to catch bugs as they happen. No more “Cannot be reproduced.” or “It works on my machine.” Our bug bash is an hourlong bug-seeking team event using Replayable to document any finds. In the end, you’ll leave more confident about your product and a more efficient way to document your bugs.

What is a bug bash?

In software development, a bug bash is a procedure where all the developers, testers, program managers, usability researchers, designers, documentation folks, and sometimes even marketing people put aside their regular day-to-day duties and “pound on the product”—i.e, exercises the product in every way they can think of. Because each person will use the product in slightly—or very—different ways, and the product is getting a great deal of use in a short amount of time, this approach can reveal bugs relatively quickly. 2

What is Replayable?

Simple Replayable Demo

Replayable runs in the background of your computer, recording an hour of screen-recorded video in a loop. Whenever a team member encounters a bug, they can grab a screen recording demonstrating precisely what happened and share it with the product team in under 30 seconds. The product team will have all the information they need to triage the issue without screencasts or worse…meetings.

Replayable is super performant and privacy-first. Video is recorded locally, and everyone has the option to crop and trim the video before uploading. Once uploaded, the video is stored encrypted at rest and unlisted until shared.

Replayable Bug Bash Program

Our Bug Bash program is a one-hour event that pounds your product for bugs and trains your team on how to open better bug reports, establishing a culture of dogfooding. Best of all, it’s totally free! Here’s how it works:

  1. First, schedule a 30-minute call with us so we can learn more about your product and test process. Typically you’ll choose one part of one product to test per bug bash. Before this call, you should have an idea of a scenario to focus on.
  2. We’ll work together asynchronously to schedule the bug bash. We’ll provide you with emails and send reminders to your team.
  3. Get to it! The bug bash will happen over a one-hour video call involving many members of your team. Here’s how it will go:
    • 15 minutes: Intro, Bug Bash objectives, Replayable Demo + Onboarding
    • 45 minutes: Team attempts to find bugs in your scenario
  4. We’ll follow up to learn about how it went and award prizes to your participants!

Not only will your team find actual bugs during our call, but your team will walk away with the tools to report bugs from their everyday dogfooding, and you’ll be able to repeat bug bashes whenever you want.

Replayable (and our bug bashes) are totally free! We’re simply seeking feedback on the app and partners to inspire our team features. Here’s the catch: We have a limited number of spots available, so be sure to schedule your onboarding call!

Introducing the new pause toggle, docs, and more!

We’re still going at it! Replayable v0.4 includes some huge updates focusing on privacy, security, and performance. Check it out, and while you’re at it, take a look at our fancy new documentation site!

As usual, we’ve gathered all of this feedback from your conversations! If you want to help influence the future of Replayable, reach out to us and let us know what you’d like to see.

Pause Recording

Want to pause recording while you do something sensitive? The much requested pause button is here!

It tooks us a long time to come up with this (surprising, I know), but we wanted to emphasize that Replayable is a desktop buffer and not just your average screen recorder. If we added a “start” and “stop” button, it would have completely changed the product.

Instead, we opted for a toggle which, while functionally similar, clearly shows that you’re disabling something meant to be enabled. And to that effect, the toggle will reset itself to enabled at every app launch.

Oh! And there’s a handy pause/unpause keyboard shortcut.

Delete the local buffer

Looking for quick way to erase any history Replayable might have? Inspired by the “Clear Browing History” shortcut in Chrome, Replayable now inlcudes a “Delete buffer” button that will obliterate all recorded video.

Just hit this shortcut and Replayable will delete everything and start fresh.

New Onboarding Page

We’ve found that a lot of our users love to send Replayable to their team. Now, it’s easier than ever to get everyone onboard. Our new beauty of an onboarding page quickly explains how everyone can get started with Replayable.


Along with creating new features, we’ve spent some time improving the performance, reliability, and design of the app:

  • Upgraded to Electron version 21
  • Prevented Windows smart screen from showing
  • New and updated projects are reflected in edit window
  • Improved the replay feed interactions and made the time larger
  • Added support for plugging and unplugging in “record all displays”
  • Moved authentication to web rather than in-app


And, of course, there’s a bundle of bugfixes:

  • Fixed a bug where “choose a display” would show upon returning from navigation or disconnecting a display
  • Fixed a bug where app would get stuck in unresponsive state
  • Fixed a bug where unlocking the mac would fail to create a clip
  • Fixed a bug where first app would fail to create a recording on first launch
  • Fixed a bug where replay video was sometimes corrupt.
  • Fixed a bug where buffer would not be deleted
  • Fixed a bug where long recent videos were incorrectly deleted
  • Fixed a bug where recording would be corrupt upon saving
  • Fixed a race condition when cropping
  • Fixed a bug where app may orphan child processes
  • Set the default replay buffer duration to one day

Get the Latest Updates

What are you waiting for? Download the latest version of Replayable below. If you’ve already got v0.3.13 or higher, your app will auto-update itself.

A super easy way to participate in Hacktoberfest

Hacktoberfest is a yearly event to encourage people to contribute to open source in October. It’s a celebration of community, learning and giving back. Hacktoberfest is a great opportunity to learn what contributing is all about, meet a new developer community, and maybe even earn some prizes along the way.

If you’re a beginner it can be difficult to get started with open-source. Sometimes it’s hard to onboard with new technology. Even once you’re familiar with the repo, tags like "#good-first-issue" might have been completed by someone else.

Thankfully this year, Hacktoberfest is counting documentation as a valid contribution!

Hacktoberfest New for 22

Documentation is a great way to contribute to repositories. Often developers don’t prioritize their readmes and tutorials. They’ll contain bugs, errors, be confusing, poorly formatted, etc. How many times have you come across incorrect or outdated docs yourself?

Documentation is hugely important to open source. Every developer that gets started with a new project needs to read the docs. Yet it’s not a priority for most developers. From the 2017 GitHub survey:

According to 93% of respondents there is a "pervasive problem" in the open-source community with incomplete or outdated documentation. Yet 60% of contributors surveyed said they rarely or never contribute to documentation.

Seems like a big problem right? Well this Hacktoberfest, you can help by making some of your own contributions to open-source documentation.

Note that if you’ll likely need to become familiar with markdown to work with .md files. Don’t worry, it’s easy and you can learn it in a few minutes.

Easy ways to contribute to Hacktoberfest documentation

  • Format the repository readme. Often times the project readmes are a loose collection of thoughts, without headings, titles, or any kind of formatting. Study that markdown guide and spruce it up!
  • Elaborate on installation steps. Developers often write very short setup steps, sometimes just a list of shell commands without explanation. You can help improve the readme by noting specific package versions, adding links to 3rd-party documentation, and explaining the setup process in plain english
  • Fix bugs in code samples. Every readme has bugs, even those created by huge companies. Try making use of all the code samples in the readme. It’s likely something won’t work or a step will be missed.
  • Enhance the readme with screenshots and videos. – Working on a front-end repo or CLI? Add screenshots or replays to the documentation to help other developers follow along.

At Replayable we’re laser focused on improving documentation and developer experience. If you need any help contributing to open-source docs, drop in our Discord and we’ll help you out.

Never miss another bug with Replayable dashcam for local development.

Capturing a 2048 bug with Replayable

How often have you encountered a bug while testing an app you’re building? How often are those bugs completely unrelated? Do you stop what you’re doing and go after them? Or just let them slide and move on?

If you stop what you’re doing to capture it, you need to remember what happened. You then need to launch a screen recorder and hope that you can reproduce the issue. If the reproduction takes multiple steps, you might waste time trying to get the application in a state for it to happen again. It’s extremely frustrating.

You might choose to save troubleshooting for later so that you don’t kill your developer flow. Who wants to stop what they’re doing to write steps to reproduce something unrelated? You know that you need to fix the bug, but it interrupts your current focus and workflow.

Why you shouldn’t interrupt a programmer

As a part of the “shift left” movement, developers now play a larger role in QA and testing. QA is no longer the responsibility of another team. It’s a combination of automation and development. Developers are responsible for finding and documenting bugs, and that competes with their ability (and love) for coding.

Once a bug is found, the developer needs to support it. It needs to be documented, then you need to tell the product team about it, and maybe there’s a meeting (or three). It’s a huge PITA. With the rise of remote work, developers can’t just grab their coworkers and say “hey, take a look at this.” Instead, they say that “it works on my machine.”

Wouldn’t it be great if you could just capture the bug when it happened in the first place? No more meetings, video capture, descriptions, reproducing steps, follow-ups, 🤮.

Trimming a clip in Replayable

That’s why we’re building Replayable. Replayable is a dashcam for developers that helps you upgrade your bug reports with clips from local development. Rather than taking the time to reproduce and explain, you can simply grab footage of bugs when they happen. It’s like a black box on an airplane. Anyone who reads the bug report won’t need to follow ambiguous instructions, ask follow-up questions, or the dreaded “what version are you on.” It’ll be in the clip.

Replayable helps you show your team what you’re talking about instead of constantly trying to explain and describe the situation. It gives your team all your information – your perspective when shit hits the fan. You get to stay focused and feel peace of mind as you know that when anything goes wrong, you’ve got footage of it – just like a dash cam.

It works just like a dashcam too. Replayable records your screen LOCALLY in the background while you work (and yes, it’s performant). Whenever you encounter a bug, just hit the hotkey or press the “create clip” button and you’ll get a video of whatever happened in the last 30 minutes.

You have a chance to trim, crop, and censor the replay before publishing. Once you publish, you’ll be presented with a quick sharing link for markdown, Jira, etc. In fact, you can even do this all in one line with the CLI. But more on that later.

Embedding a Replayable clip in GitHub

Not quick enough? The Replayable buffer records up to 3 days of footage, so you can upload Friday’s bug during the Tuesday standup. Replayable keeps its replay buffer on disk so your RAM doesn’t fill up, and it records at a low FPS, so things take up less space.

So how does it work? Imagine I’m playing 2048, and a bug pops up. Oh no! I hit the “Create Clip” button and capture it. I trim only to show me encountering the error (and the time leading up to it), then I crop and upload. I can then use the sharing dropdown to embed the replay within GitHub, Jira, or wherever your bugs go. I can go into the console.log and attach the logs to the replay as well.

In fact, you can even do most of this automatically by triggering a capture when the browser hits an error, but more on that later. For more, check out our CLI, Jira integration, and docs. Follow us on Twitter and join our beta!

How to improve your developer experience with short embeddable demos.

A readme with a Replayable replay embedded in it.

The guide below will demonstrate how you can make a readme easier to follow by embedding Replayable replays. For the full demo, take a look at the before and after.

While your readme might make sense to you, chances are you’ve probably left out some important information that other developers would appreciate. Just think about all the readmes you’ve followed. Have you ever had one where you wish the author provided better information such as:

  • Shows commands, but not their output
  • Only a documentation reference, but no examples of usage
  • Broken or missing demos
  • Need to clone and install just to run the demos
  • Detailed contribution guidelines, but nothing about usage

These problems negatively impact the DX (developer experience) for devs who want to get started with your product. Every time developers get confused, encounter a bug, or have a question, it costs them time, and they’re more likely to give up using your tool.

Unsurprisingly, it’s hard to empathize with newbies who haven’t used your repository before. You already know how everything works, and it’s hard to guess what a newbie would need to know.

That’s why we made Replayable. Replayable helps developers upgrade their readmes, bug reports, and pull requests with video so other developers can understand the context behind their contributions.

Original readme shown on the left, final readme with replays on the right.

Rather than jotting instructions down in text format, Replayable simply captures your screen as you work so you can easily attach video clips that contain an exact record of what actually happened.

Replayable captures all of the context, the running demos, the CLI output, usage, and how you – the creator – use the product. A demo is worth a thousand words, and Replayable transforms your everyday work into demos you can share with your audience.

Replayable vs Video Tutorials

Why video? While your code, examples, and prose may be enough to give developers an overview, videos capture your entire point of view. Rather than trying to explain your process manually (lossy), videos tell a complete story to your reader. In fact, 60% of developers report using videos to learn how to code.

Now if you’re not in that 60% you may be thinking, “I hate learning from videos!” Traditional videos for developers are long, boring, and unsearchable. Replayable allows you to create short clips to embed in readmes rather than long unbearable videos.

The unique thing about Replayable is that it makes adding video as easy as setting up your own project!

Rather than stopping what you’re doing, turning on your webcam, microphone, and trying to nail the perfect demo, Replayable keeps you in the flow by making it easy to add short clips along the way. Just hit the hotkey, trim, crop, and embed.

Not only that, but tutorials created with Replayable are easier to maintain. When they go out of date, all you need to do is update a single part rather than re-render the entire video clip.


Get Replayable

Let’s get started! To start, you’ll need the Replayable desktop client.

Replayable runs in the background so you don’t need to start or stop recording while you work.

Instead, you’ll simply hit Create Clip or use the hotkey to capture whatever just happened on your screen. Replayable keeps a rolling buffer locally on your computer, which you’ll be able to review and edit before uploading.

Make a new Replayable project

Replayable projects are like folders. Every time you change repositories or local projects, you’ll probably want to make a new Replayable project as well.

Use the existing guide as a baseline

Now, it’s time to make a tutorial. Your tutorial will probably mix existing setup guides and some with your own spin. After all, a lot of development is implied. It’s our job to document every nook and cranny that a newbie might not infer.

This tutorial will work on improving the getting started guide for reveal.js, a JS framework for making presentations. We’re going to follow their install guide as a base:

## Full Setup <span class="text-gray-500 font-normal">- Recommended</span>{id="full-setup"}

Some reveal.js features, like external Markdown, require that presentations run from a local web server. The following instructions will set up such a server as well as all of the development tasks needed to make edits to the reveal.js source code.

1. Install [Node.js]( (10.0.0 or later)
1. Clone the reveal.js repository   
    $ git clone   
1. Move to the reveal.js folder and install dependencies   
    $ cd reveal.js && npm install

1. Serve the presentation and monitor source files for changes   
    $ npm start
1. Open <http://localhost:8000> to view your presentation

Upgrade the tutorial with replays

Using the existing readme as a guide, follow the steps yourself in a clean environment . The first step is to install Node.js. As this is not unique to this repository and is likely well documented, it can be skipped.

Looking at the readme, the first step is to clone the repo. So do that on your machine. When you’re done, hit the Replayable hotkey to create a replay.

You can then crop the terminal and relevant browser page, then click the upload button. This will publish the replay to and make it ready for sharing!

Readmes on GitHub are created using the markdown format. To embed your replay within your readme, select Share and Markdown from the replay page. This will copy the markdown embed code to my clipboard. The markdown code includes a looping gif and a link to the replay.

You may also choose to turn the list into paragraphs to fit the embedded replays better. After every heading, paste the markdown code right after. Check out the final setup step below and the full result here.

# Getting Started with Reveal.js

Some reveal.js features, like external Markdown, require that presentations run from a local web server. The following instructions will set up such a server as well as all of the development tasks needed to make edits to the reveal.js source code.

## Download and Install

[![Downloading and Installing Reveal.js](](

Make sure you have [Node.js]( (10.0.0 or later) installed. Then, clone the reveal.js repository:

git clone

Next, move to the reveal.js folder and install dependencies:

cd reveal.js
npm install

Then, do it again for the demo step!

Launch the app, view the presentation, and make changes. In the replay below, I wanted to understand how to modify my slides, so I launched VS Code and edited the first slide.

This is the kind of instruction where a video can be extremely helpful. While the text may make sense to you, a newbie might make errors when running npm start. They might not understand the relationship between the browser and the terminal in regards to “localhost,” and they probably don’t know what “monitor source files for changes” means.

Not to mention, they probably can’t infer what will pop up once the demo runs. In fact, you probably don’t even know yet! So as you get the demo running for yourself, creating clips helps explain to others what the resulting output of these instructions is and provides context for how you got there.

## Run the Demo

[![Setting up and running the Reveal.js Demo](](

Serve the presentation and monitor source files for changes:

npm start

Then, open http://localhost:8000 to view your presentation!

Any changes you make to the source files will automatically be reflected in the presentation.

Publish the Tutorial

That’s it! You’re ready to publish. If you’re contributing to a repository, now you can open pull requests. Replayable embeds are supported everywhere, GitHub, Jira, WordPress,, and more!

If you want to try Replayable out for yourself, join our beta and come hang out with us in Discord!

Our Story

Me, Alex, and Natalie on our way to a music festival.

Even before I moved to Austin, I met the folks from ATX Hackerspace (now Asmbly) at SXSW. When I made the move down here for good, I joined their community and co-working space. 

The hacker house on Hampton Road.

One day, I noticed Natalie wearing a t-shirt from a startup where my roommate worked, Synesthesia. I asked her if she knew my roommate, and since the company was only five people at the time, she did.

Recognizing each other’s talents, we quickly became friends. Years later, Natalie ended up moving into our hacker house in Hyde Park (Think project room, pool, jam room, and pounds of steel in the backyard.).

We both spent time in different startup ventures; Natalie moved on to work at Senseye and I left my job at PubNub to start Haxor. At Haxor, I was conducting UX research on developers to better understand why every developer complained about docs and what we could do about it.

I noticed a similar theme in the problems that came to light. Developers struggled with communicating their issues when they needed help. There’s too much information required to provide context, and developers have too little time–and patience. 

I started to prototype screen recording tools that developers could use to provide feedback to the teams responsible for managing APIs and SDKs. Eventually, I found that the most valuable thing we could do for those teams was to provide them with a short “instant replay” every time they had bugs or wanted to submit feedback. The teams didn’t have time to watch hour(s)-long screen recordings, but instant replay provided just enough context about what the developers were doing.

After testing this software with more than 250 developers, and getting positive feedback from pretty much everyone, I knew there had to be a better application than UX testing. That’s when I asked Nat to come aboard.

A prototype (

And since we had already lived together and worked on a dozen projects together, we knew we’d make a great team. Nat had also been there through the first years of Haxor, and she’d frequently been the only person I’d talk to IRL the entire day. Natalie was a free agent, though now in Portland, and was looking for the next thing.

When I made the pitch to Natalie, she immediately understood the problem. “Both of us believe in the core tenant of documentation as the lynchpin of development,” is something I grabbed from an early call.

Natalie building a speaker box in our backyard.

With everyone going remote, there was much higher interest in documentation and remote communication. 

“We’re being forced to move into this async remote mindset as a culture. And that is the mindset in which this product is the most useful” she said.

Replayable dashboard

Together we want to bring the benefits of Replayable to every developers’ desktop as part of their everyday workflow regardless of where–and when–they work. Developers hate repeating themselves, and they hate breaking their flow. Replayable lets developers open bugs, close pulls, and create documentation faster by capturing video of their workday. We think that Replayable can help developers become more productive, learn, and empathize with one another.

Announcing the Replayable Beta!

After three years of working to understand developers with the help of fantastic clients like AWS, Mailchimp, and SAP as part of Haxor, we found a clear pattern pointing to the root of poor developer experience.

Developers don’t have time to share knowledge.

There’s too much information required to provide context, and developers have too little time–and patience. Understandably, they don’t want to break their flow to explain things.

What is your biggest challenge in software development?

In fact, sharing knowledge was rated as the #1 challenge for software developers1. In second, was “capacity,” meaning developers just don’t have enough time to write docs.

In open source, 93% of developers list lack of good documentation as the #1 problem, yet 60% of developers report rarely or never contribute to improving it2. Developers agree that their resources are not strong enough, yet they are not contributing to fixing the problem.

So what did we do about it?

Footage of a Haxor developer experience test.

We solved the problem! While conducting developer tests, we found that developers were more likely to submit feedback and bug reports when they could attach a screen recording.

This worked out well for everyone. The developers could write less, code more, and our clients, API companies who wanted feedback, could review the screen recordings to learn everything they needed to know.

After testing this software with more than 250 developers, we isolated the one power feature that everybody loved. Developer instant replay.

Introducing Replayable!

Our new tool, Replayable, has officially been launched in private beta! It records passively in the background as developers work and catches crashes, one-time errors, and things that can’t–and now don’t need to be–repeated when asking for assistance.

Developers no longer need to type “Steps to Reproduce.” All they have to do is send a replay! We think Replayable has the potential to increase developer productivity on a global scale.

It can save you and your team tons of time, and it’s not just for research studies with big companies. We want to bring Replayable to every developers’ desktop as part of their everyday workflow. They spend an incredible amount of time explaining their work. Think of all the writing, meetings, miscommunication, and headaches saved with this tool.

If you’re as excited about this as we are, join our beta! Right now, we’re looking for front-end developers who are building products with a team to try out our app

What’s New in 0.2.6: Share GIF Previews!

We know gifs are all the rage. What’s better than a static image, gif! We’re happy to announce the ability to generate gifs.

Improvements & bug fixes

  • Fixed an issue that showed videos in the desktop feed that were older than 3 days.
  • New Zendesk help center
  • Fixed an issue in the edit window preview that was causing a black window