The most magical experience,” “a true game-changer” — not exactly the sentiments you expect to unanimously hear from developers, famously selective and opinionated about their tools. But we heard this over and over again when talking with devs about Replay, which enables a dramatically better debugging experience and easier way to understand your codebase. 

Bugs in software are inevitable. Today’s web applications are growing in complexity due to evolving frontend frameworks, rapid changes to browser engines, and distributed backend architectures with 20+ microservices powering each app. It’s becoming harder to manage state and diagnose the root cause of an issue, making bugs 10x harder to fix. On top of that, there’s also an incredibly lossy communication channel of different stakeholders (i.e. product managers, customer support teams, designers, end users) trying to describe bugs by using screen recordings, screenshots, and paragraphs of text. All of this combined makes it extremely challenging for developers to replicate bugs. And even after investing all this effort, the bug may be timing-related and disappear.

This is where Replay comes in and alleviates developer friction. It’s the only product we came across that allows developers to record the entire state of the application, replay the code execution, and inspect the application state by moving forwards and backwards in time. This gives developers a deeper understanding of all the code interactions with side by side visuals of the app recording, enabling complete reproducibility of the bugs with barely any performance hit. In chatting with Replay users from Facebook’s React team and developers at Stripe, Sourcegraph, RepLit, CodeSandbox, and VSCode, we heard over and over that using Replay was like magic. 

Replay’s founders, Brian Hackett and Jason Laster, have dedicated nearly a decade to building this product, starting with Brian’s PhD work at Stanford. Companies like Microsoft and Apple have long tried to tackle this problem by building time-travel debuggers but Replay was the first to make the record/replay function work with extremely low overhead, across any browser and any runtime. 

Today, Replay is announcing that their product is generally available to anyone who would like to record their first “replay.”  They are launching the Replay browser and releasing Replay for Chrome, and Node.js in beta. It’s been a massive technical undertaking but underscores that the core of the company will always put developers first — providing the most delightful user experiences and enabling seamless collaboration across teams. 

a16z has always invested in open source projects and tools for the community. We’ve learned some critical lessons working with teams like Github about how important it is to focus on managing public repos in order to build trust with developers and bootstrap the network. We were hearing the same organic pull from open source maintainers asking for project contributors to use Replay to record issues and attach replays to every bug report. Even though it’s still early days for the company, seeing this kind of traction is a strong signal in what’s to come for Replay. We look forward to partnering with Brian, Jason, and the Replay team on this journey and seeing more public replays. 

The most magical experience,” “a true game-changer” — not exactly the sentiments you expect to unanimously hear from developers, famously selective and opinionated about their tools. But we heard this over and over again when talking with devs about Replay, which enables a dramatically better debugging experience and easier way to understand your codebase. 

Bugs in software are inevitable. Today’s web applications are growing in complexity due to evolving frontend frameworks, rapid changes to browser engines, and distributed backend architectures with 20+ microservices powering each app. It’s becoming harder to manage state and diagnose the root cause of an issue, making bugs 10x harder to fix. On top of that, there’s also an incredibly lossy communication channel of different stakeholders (i.e. product managers, customer support teams, designers, end users) trying to describe bugs by using screen recordings, screenshots, and paragraphs of text. All of this combined makes it extremely challenging for developers to replicate bugs. And even after investing all this effort, the bug may be timing-related and disappear.

This is where Replay comes in and alleviates developer friction. It’s the only product we came across that allows developers to record the entire state of the application, replay the code execution, and inspect the application state by moving forwards and backwards in time. This gives developers a deeper understanding of all the code interactions with side by side visuals of the app recording, enabling complete reproducibility of the bugs with barely any performance hit. In chatting with Replay users from Facebook’s React team and developers at Stripe, Sourcegraph, RepLit, CodeSandbox, and VSCode, we heard over and over that using Replay was like magic. 

Replay’s founders, Brian Hackett and Jason Laster, have dedicated nearly a decade to building this product, starting with Brian’s PhD work at Stanford. Companies like Microsoft and Apple have long tried to tackle this problem by building time-travel debuggers but Replay was the first to make the record/replay function work with extremely low overhead, across any browser and any runtime. 

Today, Replay is announcing that their product is generally available to anyone who would like to record their first “replay.”  They are launching the Replay browser and releasing Replay for Chrome, and Node.js in beta. It’s been a massive technical undertaking but underscores that the core of the company will always put developers first — providing the most delightful user experiences and enabling seamless collaboration across teams. 

a16z has always invested in open source projects and tools for the community. We’ve learned some critical lessons working with teams like Github about how important it is to focus on managing public repos in order to build trust with developers and bootstrap the network. We were hearing the same organic pull from open source maintainers asking for project contributors to use Replay to record issues and attach replays to every bug report. Even though it’s still early days for the company, seeing this kind of traction is a strong signal in what’s to come for Replay. We look forward to partnering with Brian, Jason, and the Replay team on this journey and seeing more public replays.