💡 Founder Spotlight: Jason Laster

Welcome to the Founder Spotlight of Jason Laster this week. I'm Evan Johnson. I'm from Cloudflare's product security team and this week we're having tons of awesome founders on Cloudflare TV. Jason is the CEO of Replay.io. It's an awesome product. Jason, want to tell us a little bit about yourself. Sure. So I co-founded Replay.io a year and a half ago with my co-founder Brian Hackett. We both had been at Mozilla. He had been at Mozilla for 10 years working on every part of the browser, primarily JavaScript, so SpiderMonkey. And I'd been a tech lead for the Firefox debugger for four or five years. Nice. And I'm curious, how old is the company? When did the company get started? Yeah. So we'd been working on the technology at Mozilla for four or five years as well. We really, really wanted to do it there. I tried everything we could and eventually became pretty clear it was time to spin out. And Brian spun out January of 2020, I want to say, or 2019 even, shit, two years. And I spun out the summer of 2019. So for me, about 18 months. Okay. So it was pre-pandemic, you started working on this. And then I'm guessing as throughout the pandemic, the company kind of formed. That's right. So Brian spun out January of 2019. Everything seemed fine. I'm beginning to consider it around March when things are not fine, but he's making a ton of progress. It's seeming really exciting. My wife gave me six months to really go for it in June of 2019. We raised money while I was still at Mozilla. So we were talking to investors and they were really excited. Like, okay, let's go for it. And we started officially July of 2019. Wow. So officially the company started July, wait, 2019 or? Maybe it's 2020. I apologize. All good. And so the company as a whole is about 18 months from when it was officially made. Know what's happening? I didn't realize that in a couple of weeks, it's 2022. So of course, it's 2020. Yeah. That's wild that it's about to be 2022. And the name 2022 doesn't give me much to look forward to. Do you want to talk about what it is, what it does? What's the value proposition of the product? Because I'm sure there's a lot of people out there who aren't familiar with replay. Absolutely. So we're building the first time travel debugger for the web. And what that means is let's say hypothetically, I know this never happens. You find an issue in Cloudflare's admin dashboard. You're like, oh shit, that's not right. Maybe a Cloudflare worker says they're five up, but there's only two. I you can record that with replay, share that replay in the Slack front end channel, and anybody could look at it. And when they're looking at the replay, they can watch the video, comment on the video. But what's really exciting is they can go over the dev tool side. And effectively, they have something like Chrome dev tools where they can add a breakpoint, add a print statement, inspect an element, look at the network logs. And this is if the admin dashboard is running live for them for the first time. But of course, we're running in the cloud. So we got our name because we're able to record a browser tab, or really any JavaScript process, it could be a node process, and then replay it later. Nice. And I guess I'm curious, as you're making the company, you have this great developer tool and this belief that this is valuable and everything. And your wife's support for six months of experimentation and making this a real thing, which is also very important. How do you go from taking that from an idea to getting venture capital to forming a company? What was that like? Yeah. So the raising was in many ways, the easiest part. Because the idea is so crazy that if it's possible, then of course, it's valuable. But for me, the beginning is really when I was learning how to program. I graduated college, went to this program called Recurse Center, which is like a writer's retreat for programmers. You can build your own kernel, you can build your own language, you can work on any open source project you want to work on, really anything. And you're with other really brilliant people who are doing it at the same time. So for me, I went there and I realized I could hack on debuggers. So Ruby's REPL Pry was something I worked a lot on, but I also looked at BPython and just became fascinated. Can you work on your runtime's environment itself? And I think it might have been at Recurse Center, or a couple months later, I realized that you could actually work on Chrome DevTools as well. DevTools are written in HTML, CSS, and JavaScript. And at that time, Brett Victor also published his seminal videos on time travel debugging as well. I was like, wait, if you could record, rewind, and replay, and look at what's happening, you can really understand the software as well. So I became fascinated with the idea of time travel debugging at that point, and have wanted to work on it ever since. My co -founder joined Mozilla in 2010. And around that time, Rock, Kyle Hue, and others at Mozilla had just built the first time travel debugger for C++. So he was using RR to look at the JavaScript engine and other parts of the browser, just like a lot of other Mozilla engineers were as well. And it became obvious that you kind of needed that if you were going to go up against Chrome and the legions of engineers. Because Mozilla has this very scrappy culture where it's one of you against the engine. Can you understand the engine? And RR was that tool that made it possible. So for us at Mozilla, for Brian, it was like, wait, if this is so valuable for me working on the platform, can we add it into the platform so any developer can have it if they're building for the web? That's fascinating. And how applicable is the work that you're doing now to other languages outside of the browser? Are you kind of tied to the browser for now? Or how do you think about that? Yeah. So our mission is to make software more approachable and understandable for anyone. So that's my wife, who's a product manager. If there's a question that she has about her product that she's working on, she should be able to record it. A developer should be able to look at it, add a comment on a line of code, and then she could look at that function as well, bring her in. We think that the recorder that we built is universal to runtime. So at this point, we support Firefox, Chrome, and Node on three platforms, Mac, Linux, and Windows. You kind of need Linux for the cloud. And there are a lot of developers out there on Windows as well. So we want to be universal. It's an open question whether we can take our recorder and apply it to Ruby, Python, Java, .NET. The way we record, I think, lends itself really well to those other environments. But we have to try it. Nice. I'm rooting for you. I think that just thinking about the security applicability of this thing, like trying to reproduce security bugs, it can be racy. It can be hard to reproduce. It can be hard to track down and find good tools that even help you go through software, depending on the language or maybe as a developer. There's great tools, but you're not super familiar with it as a security person. I just think that there's a dearth of really good companies and tools out there that help debugging. So I'm rooting for you all. There's a great security time travel debugging story. This brilliant engineer George Hatz started Kama AI, built one of the first self -driving cars with an iPhone on his roof. And he would go to security conferences with a time travel debugger that he built and just win and beat teams that had 10 people, academics, everyone. And he always attributed to the tool. He was like, hey, it's not fair. I can record it once, look at the disassembled environment, and then just understand what's happening. So if there's something really hard, it's really a reproducibility problem. We can record it once, and then you never have to worry about reproducibility. You can just zoom in on that thing. That's interesting. Yeah. That's funny you mentioned GeoHot. We have another famous CTF-er on Cloudflare TV later this week, Dr. David Brumley from the Plaid Parliament of Pwnage and For All Secure will be a founder spotlight that I have on later this week. I got to introduce you too, because you're, I guess, kind of in similar spaces. But anyways, I digress. Yeah. In the security space, I definitely see the applicability of this kind of thing, ripping into binaries, looking at all sorts of things. Okay. So how do you go, you have this idea, you've raised venture capital, and it's not something anybody in the world has ever seen before. It's not like you're not remaking Excel or something that everybody kind of sees the value of this thing. Like how do you go about finding product market fit? What has been your strategy here? It's not a better why kind of problem where everyone says, I have why, I hate why. Do you have something better? The two challenges, there are a couple of challenges, but the two primary ones are one, this thing's so crazy, it's probably not going to work. That's one. But most people will say, all right, I'll give you the benefit of the doubt. If it works, cool. The second one is developers don't use breakpoints. They use print statements, right? You could talk to the best developers in the world who've been building the craziest systems, and you ask them how they debug, and it's kind of similar to the way that you would start if you're just working on your first Hello World. You look in, you're like, huh, I have no idea. Let me add one print statement here, like rerun, look at the logs, think. It's like maybe they do more thinking, but it's like the same process. So the other crazy thing about replay where we really just had to pause was how do we help people transition from print statements to our crazy time travel debugger? If we just went to them and like, hey, breakpoints are better than print statements, and you're going to love this time travel thing, we would have lost them before we even started. So we spent a lot of time thinking about what that meant, and where we landed, which has really resonated, is, hey, we know you love print statements, but you hate this like search the code, rerun, view a million logs problem. You know, you can find what you're looking for, add another million logs. So with replay, you can record it once, add a print statement, and then you can see those logs immediately. You don't have to worry about rerunning, and then looking at the logs, you just add it, see it, and if you don't like it, you can discard it. Oh, yeah. I'm guilty of that debugging by printing, and it's definitely hard to change workflows as well. It can be a challenge. Should I show you what replay looks like? I'd love to do a demo. Yeah. Let's see. So I had this replay open that I was just showing a friend, and maybe I shouldn't share this with the world, but I think it's kind of amazing, so we'll use it. This is our Carta dashboard for replay. So you can see, you know, Carta account, record replay. You know, as an employee, you're used to Carta being a place where you can check your option grants. As a founder, I'm used to Carta also doubles as a place to manage your cap table, get your 409A fair market valuation, those kinds of things, and this is not great, but sometimes Carta says that your FMV is a NAN. It's like you're running an NFT. It does not compute. The other funny thing about this video is if we go back and watch it, you're going to see a lot of things that just every website does, and it's kind of hard to get right if you can't just slow it down and see what's going on. So this is Cloudflare loading. Sorry, not Cloudflare, Carta loading. Watch the spinner right here. So it starts off at the center. This looks good. This is what they designed, but as the data loads, see that jump right there? Interesting. Something's going on there. Yeah. These are the in-between states where we don't really design them. We just like start with A, we land at B, and then there's like all these things in the middle, and with replay, I can go in, inspect this element, see why the positioning was applied the way it was, and then what changed it. So maybe there was like a React component that was rendering. I was like, oh, I didn't expect to have all this data come on the page, but not have a secondary header. Another funny thing to me is at some point, we get a second spinner too, which is like this spinner problem where another thing is loading, and that gets a spinner, but this thing's already loading, and we didn't know about the two, so we can't just show one global spinner. And so you're recording a web page loading, and all of the instructions running, and how it's rendering, but can I go see like the JavaScript exactly recorded backwards in the JavaScript? Yeah. So the funny thing is we're not recording a video. Like we're showing you a video now, but we're not recording a video when we're recording. We record the browser input a little bit like how you record the airwaves going into antenna for an old TV. Just the necessary bits needed to tell Chrome, here's a recording, run. And it thinks it's in a normal environment with a normal user, a normal Internet, but it's just reading from the recording and in the simulation. This means that we can replay, and every time the browser paints, we paint too. So we can recreate the video after the fact. But yeah, let's go over to DevTools. So another founder story, when we started, we were like, hey, let's just give people Chrome DevTools or Firefox DevTools. And then we realized we hit the breakpoint problem really hard because people don't debug in the debugger, they debug when they add a print statement in their code, in VS Code. So we redesigned the UI to feel a little bit more like you're in VS Code where you have that familiar left sidebar with the source explorer, you can search for anything, search is really important. And then we do add a print statement, it shows up here in the console. So I'm going to quickly remove this print statement, go over comments. And you can see I've left a couple comments in the code here. You know, when I initially found this, I was just going to send it to somebody at Carder. I post on Twitter, I'm like, yo, this is funny. But then I just wanted to give myself five minutes to see if I could figure out what was going on. So what I did was I did a quick search for fair market value. And just began looking at the code, just like all here. And that quickly took me to this spot where we're using the constant for fair market value. And what's great about Replay is I can go in, add a print statement, and it just shows up right here. And I can expand, look at the value. So effective date, this is our report ID for the 49A. Primary price, no, not great. Provider, umbrella ID, no idea what that is. But I can just hover too. I can go report, primary price, no. And what I think is happening in this function is trying to take your valuation in pennies and turn it into valuation in dollars. You know, integer to decimal, integer to float. And because our price is coming back as null, that null can't be coerced into a float. So it resolves to NAN. And I just want to show you where that's coming from. So we do have everything you'd expect in a debugger, like a call stack, the scopes, you can evaluate expressions. And we could use that to go up the call stack and look at the React component that Carter uses to just render the entire application. And I'm going to scrub backwards, which is our fancy time travel debugging feature. And then again, just come in here, add another print statement, and we can take a look. So I can click, add a print statement, we have four logs. And maybe I can see what's in here too by logging like data.reports or something. Or the data requests, data reports. So the first thing, which is kind of neat, is it's initially undefined. But it is rendering a couple times. And the second render is where it jumps here. That third render still actually shows the header. That's nice. And then it's that fourth render where we actually have the report. So we could do things like add that print statement, see what the values are over time, see what the application looks as well. Nice. This is fascinating. There's a ton of tools to really dig into as far as you need to dig into the people's code here. And we've gotten people looking at the craziest things, like recording the TypeScript compiler. But the examples that we really like are when someone joins a team and they just want to get started. Or when someone opens a PR and attaches a replay of the fix. So the reviewer doesn't have to pull it down and reproduce the problem or think through that scenario. They can just look at the replay. So it's everyday collaboration opportunities that are really exciting to us. Yeah. I'm curious how you've gone and navigated as a new product that is so different, how you've navigated sales and trying to get traction in sales. Because it seems like something where you put it in front of a developer and they'll be like, oh, this is really cool. But then you're like, OK, let's get an invoice signed. And they're like, OK, how do we price it? How do we value it? And it's almost like companies don't know how to pay for it. So fortunately, we have not had that problem. The nice thing about where we're at today, so technology is absolutely disrupting the world. Teams are getting bigger and bigger. So if you're a developer, you've never had more bugs in your backlog than today. And it's never been harder to reproduce the problems. More feature flags, more environments, more microservices. Code is changing 50 times a day. So if you got a bug last week, you're like 1,000 deploys behind or commits behind. And because of that, replays really resonated at larger companies too. So we started working with open source maintainers on their libraries, like complicated use cases where you really have to slow down and understand it. And that resonated. And now we're looking at bringing some of the largest companies online that are really hitting these collaboration challenges as well. Love it. That's awesome. All right. Well, I'm glad you don't have the problem of trying to sell something completely new and people not getting it. That's good that they understand it. And I always imagine if you're paving a new path or something, then the finance department will see it and be like, what is this? Yeah. Maybe that will come. Put time travel debugger into the line and be like, hmm, I haven't seen this one before. That is certainly possible. I think we're probably going to fit into the async collaboration space just as much as the production infra space. So a cross between Datadog on one end and Bloom on the other, that could be interesting from a financing perspective. But we've really benefited from the fact that folks at large companies see replay and are like, I don't want to work on this code base without replay. And they've been pulling it out of our hands. Cool. Yeah. So our investors ask us, like, hustling and growth. And we're like, we don't know how to hustle. We're just trying to keep up with demand. Nice. So also, I'm curious the technology side of things. How has your role as a CEO changed from it being something that you're trying to make real to hiring a real team and getting demand? How's that been for you? Yeah. So it's been a transition. Absolutely. The most important thing for me is the hiring side, obviously. COVID has been very disruptive. And in many ways, that's actually helped us, which is counterintuitive. But if the Google cafeteria is no longer as appealing, because you're all remote, then there's an opportunity to pick something that's really meaningful and exciting. And with replay, we have this great, we call it bi-sync culture, where we do a ton of async, a lot of writing, a lot of thinking on the browser, how DevTools works, product collaboration. And then we jump on Zooms all the time and are synchronously helping each other too. So it's a really fun culture to be a part of. And I guess I spend my time talking to the most brilliant people about time travel debugging, and a lot of them say, like, hey, let me just wrap up this one thing and then come on join. Nice. Okay. So I'm curious. I remember when Cloudflare IPO-ed, Michelle, our co -founder, went out and did a company all hands and was like, some things change, some things stay the same, and we're going to make sure that the important stuff stays the same. To you, as the company grows and scales, what are the important things that you want to stay the same? What's it we want in the company DNA? We are really whimsical. That is important. Okay. So close your eyes and think of your typical DevTools and just how stale it is. It's like DevTools built by developers for other devs, and it's like professional tooling from the 90s. That's not us at all. We love bright colors. We love just trying things and just throwing them out there. So we put a lot of whimsy into the UI and into the experience that just shouldn't feel like your typical DevTools. I've never in my life heard the word whimsy before. There you go. We're different. Nice. Okay. So whimsical, I guess freedom to try things, freedom to experiment, definitely. And then curiosity. So we get to bring people on who are curious about how runtimes work. So they want to go deep into the garbage collector, into the JIT, into the compiler, into how JavaScript does bytecode and how the call stack works and scope chains. All of these complicated pieces that you kind of have to begin to build a mental model of to be able to play computer or send your software. And we get to go down there and think about it, and then think of ways to make it easier for people to understand it. So they're not thinking so much about the scope chain or thinking so much about the call stack, they just get to play with the DevTools and understand what's going on. So we have these just really fun, collaborative, creative folks looking at the guts of the system and then exposing the right APIs to make it easier. So for instance, recently we just announced the network monitor. And sure, we can show you the requests that are made, but we can also click a button and play to each one of those requests and see who made the request, who handled it, and then learn a little bit more about what's going on. Love it. So experimentation, curiosity, and this, I don't want to say never-ending quest, but this freedom to go in and learn all about the guts of these things. Anything else? I think whimsy and curiosity captures it. Love it. That's awesome. Cool. So anything you want to cover or any, what's your roadmap look like? Gosh. So I think our roadmap is really simple. If we go back a bit, this time last year, we were happy when it worked at all. So it was like, let's get a nine in there on your classic P90, 99, those kinds of things. Then it was- Like 9%. Got it. Yeah. Or 1.9%. Okay, we got you too. Great. Then it was, let's make sure it holds up when we have an open source developer who's using it. Okay, we can do that. Proof of value. Great. And then it was, let's get it to the world in a way that we feel comfortable, it's secure, and we can tell our store and people can learn about time travel debugging. Today, it's about onboarding, enterprise customers, teams, those kinds of use cases where people expect to wake up in the morning, go to Jira or GitHub, find an issue and like, click, there's my replay. And it all just works like fast recording, fast replay. And we've just landed the network monitor, the elements panels coming soon. So we have all the bones in place, and it's about just providing that seamless experience where everything is fast, smooth, stable, precise, secure. Nice. So you actually think that feature you're pretty much built out. Yeah. Nice. And then it's really about tightening all the bolts and making sure it's as good as can be and lots of incremental improvements, I'm guessing. Yeah. There'll be things once we hit enough nines. But today, the fact that someone can look at a replay and add a print statement is so compelling, that that's more than enough to get out there and support folks. Love it. Well, reliability is definitely a feature too. And it's funny that you... I feel like we spent a lot of time on replays narrative and about how you think about it. And actually, on the founder spotlight I did with Calvin Frencho on Monday, I said, what's your advice to founders? And he said, spend a lot of time on your narrative. And it's really important. So I thought that that was neat. Sounds like you almost listened to him. But Jason, we're almost out of time. I really appreciate you coming on. It was awesome.