The team talks to Matt Arbesfeld, cofounder and CEO of LogRocket, about the most challenging problems he’s solved for customers, how machine learning is shaping the next generation of LogRocket solutions, and why side projects that teach you how to experiment and make mistakes are just as (or even more) important than formal CS curricula.
LogRocket helps software teams create better experiences through a combination of session replay, error tracking, and product analytics.
LogRocket’s machine-learning layer, Galileo, cuts through the noise generated by conventional error monitoring and analytics tools to identify critical issues affecting users.
LogRocket is hiring, so check out their open roles or connect with Matt Arbesfeld on LinkedIn. You can also give LogRocket a free trial.
[intro music plays]
Ben Popper Are you looking for demos and innovative use cases on how to build smarter and more reliable automations with built-in connectors, low-code, integrated AI, and more? Explore UiPath Dev Dive Series at bit.ly/dev-dives_2023. We'll be sure to put that link in the show notes. Check it out.
[music plays]
BP Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. I am Ben Popper, Director of Content here at Stack Overflow, joined as I often am by my colleague and collaborator, our technical evangelist, Matt Kiernander. Hey, Matt.
Matt Kiernander Hello. Nice to be here.
BP We have a great guest today, Matt Arbesfeld, who is the CEO over at LogRocket. We're going to talk a bit about his background, his company, and a few stories that I think will be interesting to all developers. So Matt, welcome to the show.
Matt Arbesfeld Thanks for having me on. I'm really excited to chat with you guys.
BP So the first thing we always ask guests to do is just step back for a little bit. How did you get into the world of software and technology? Did you start as a kid? Did you come to it late in life? What brought you to where you're at today?
MA So I'm in my late twenties, and I think growing up was a really interesting time in software development where things were not as smooth as I think they are today to get set up. I remember in middle school I was really excited about building games and I tried 3, 4, 5 times to build a game, but getting compilers set up and reading all these books in C and C++ was just so complex. I didn't have anyone in my family or life to really help me out there. So it took me all the way until probably the end of high school when maybe all the neurons were firing correctly and I took an AP computer science class and that's when I first started programming. And then throughout college obviously I took classes and did my best, but I feel like most of my college actually was just spent in my dorm room coding various side projects, trying to build different little businesses. And so that's really where I probably did the bulk of my time programming– in college.
BP Gotcha. You had the entrepreneurial bug?
MA I did, I did. And I’d say my co-founder and I, Ben, we've been best friends since about a month old, and throughout our whole lives we just enjoyed building things together. So we definitely care about building businesses, but really we were excited about building new things and bringing new innovation to the world, and that was sort of the root of what inspired us to build things together.
MK Can you talk to some of the failed ideas that you had, or successful ones you had during those college years?
MA Yeah. So I was really excited about mobile applications. This was 2012 to 2016 and so you were seeing the rise of things like Foursquare and Uber. So one of my more successful ideas was a mobile game that my friend and I worked on, and we got it to a few million downloads and that was really successful. One of the more embarrassing ones was this social app called Cluck. And what Cluck enabled is, I had a problem where I would be texting my friends and I would send a text and it would take an hour for them to respond and I was like, “This is really frustrating. What if instead of that delay, I could just cluck them and then we'd enter a real-time text messaging conversation?” But we spent months and months on this and no one used it. It was just really a true failure of a project.
MK It sounds vaguely reminiscent of –if anyone watched The Office here– one of the young entrepreneurs there started a company called Woof, which basically, instead of sending out a text message, it sent you a text, a fax, an email, a voicemail and everything else to try and get the attention of the person at the same time.
BP Right. The rule of thumb is, don't name your company after an animal sound, onomatopoeia. I don’t know, we'll have to stop and think if there's any successful companies that have been animal sounds. And so you said you ended up eventually meeting your co-founder. What's the origin story there of how you two met? And maybe that's a good intro for you to tell folks a little bit about what you're working on these days at LogRocket.
MA Yeah, so we actually met at about one month old. Our parents were friends and introduced us basically in the hospital, so we've known each other our whole lives. We ended up living together one summer between our junior and senior years of college in San Francisco, and we'd come back from work and be just bored, where normal kids would go out and party, or I don't know, do stuff like that, we would just code and work on projects. And so I had experienced a challenge in my work where we would launch a new application or a new feature, and then users would come in and they'd start using it. They'd inevitably run into some type of issue, and immediately they'd email my CEO or they'd send in an issue to support and she would then forward me these issues and I'd be pulling my hair out trying to figure out what happened to the user. Were they clicking a button wrong? Were they just confused? And so that problem of understanding what's happening to your users, where they are struggling, what's causing problems, that's what originally inspired us to start LogRocket almost eight years ago now.
BP So I've done a bunch of different interviews about observability and telemetry, logs and traces and metrics and monitoring. When you are working with developers these days and your clients, what are the most important things, the most important signals? How do you gather them together, and are you using some of the open source tooling that's available in the space that I think appeals to people because they don't feel it has the same vendor lock-in?
MA Good question. So although we're called LogRocket, we're actually much different than your observability tools like a Datadog or a Prometheus. We are purely front end focused, so we are just capturing what's on the UI and the user interface. And instead of capturing just logs, we actually capture what appears to be a video replay of what the user's doing. So you can actually go and see what the user saw on their screen, where they clicked, where maybe their mouse is hovering, and so it's a lot different than your kind of typical telemetry and observability information. It's this kind of new really interesting data set of user experience data. So for that reason, there actually are not open standards yet for this type of data capture. It's still so new. So we definitely are supportive of things like OpenTelemetry and integrate with that, but the data we capture ourselves is so unique that there's no open standard for it right now.
BP Gotcha.
MK When you're saying maybe you could understand where the mouse is hovering, in terms of a technical integration, are you just looking at the events that happen on the webpage and then creating kind of a story or an idealized version of what the user is seeing? How does that tracking actually work?
MA So what we're doing is we're tracking the DOM over time. So we're looking at, the user saw this certain DOM structure at the beginning and then this is how it changed over time, and then we're reconstructing that DOM when you go and play back that user experience. We're not replaying what the user clicked on or what they typed in, we're actually capturing what they saw. And so that allows us to create a faithful reproduction of exactly what they saw in the UI at the time of the issue.
MK So you're basically getting snapshots along the way. And so if a user encounters an error or something went haphazard, you are able to see the complete DOM tree, and I'm assuming looking at the diffs between those to surface potential issues or errors.
MA Exactly. And what's really powerful about that is that you can then look at the user behavior and see, is someone really frustrated by this error or this issue? Are they clicking a lot, or are they going back and forth between pages? And then we can use that information to better surface the important problems to you as a developer.
BP Gotcha. And so is that a manual reconstruction in the sense that you said it's almost like a video recording? You go step by step on an incident, try to unpack it, and then come up with a solution? Or is there some kind of AI or automated process you can use to run analytics on this that would say, “This is probably the issue,” and then maybe a human in the loop to affirm that?
MA So it's both. So where we started was just that straight recreation. So Ben, you have an issue. I can go search for your experience and see exactly what you did over time. But at scale, you don't have time to watch potentially millions and millions of these videos, and so we've developed an AI called Galileo that scans all this information and shows you, “200 people ran into this error and they were really frustrated by it, and it hurt your conversion rate by 3%.” We're really excited to be able to use machine learning on this massive trove of data that we've collected over the years.
BP So I guess I want to hear some war stories. What are some of the most interesting or difficult problems you've had to unpack, unexpected errors that you couldn't replicate? Tell us some stories about issues you’ve solved for clients that you think would be interesting to the developers who are listening.
MA There've been a lot of interesting problems in the recreation of the DOM. We now have over 3,000 customers and probably another 4 or 5,000 on the free plan. And so there's tons of applications and there's so many different ways that people are building their UIs, and so making sure that what we're recording is the same as what we're playing back, that has had some really interesting things. I've seen some customers, they've had like 10 body tags in their app, or they've had thousands of nested divs. Just crazy DOM structures that have made it really interesting to debug those issues. So definitely I learned a lot about different ways you can build web apps just seeing the wide range of people build their apps today.
MK I'd love to know– you briefly went over the origins of LogRocket. I'm curious if you can tell us more a little bit around how LogRocket came to be. When you quit your job to do it full-time with LogRocket, what was that process like?
MA So I'm very fortunate in that we actually started the company in school. So we were going into our senior year, that's when we wrote the first line of code. And so in that environment, you really can't fail because you're just a student and on the side we were working on this project. And so we ended up launching sort of our predecessor to LogRocket in our senior year and it really took off. And so we then used that traction to raise our first round of funding. So there wasn't a time when I had to make the difficult decision of, do I leave my safe job to go work on the startup? It was sort of a natural thing that happened as we were finishing school, we just went full-time into working on LogRocket.
MK And for anyone who's currently in university and is entrepreneurial-minded, what advice would you be able to give to students who are currently going through their CS degree programs and looking to build their own businesses?
MA Yeah, I think at least for me, it was the best time to be working on side projects because you can't fail. Either they don't have traction, then you can come work at LogRocket, or they would take off and have a great startup to build on top of.
BP You can fail your classes, but I guess maybe you managed to do both at the same time.
MA You can fail your classes, but we all know that doesn't really matter.
BP Gotcha, okay.
MA Yeah, definitely experiment. I probably spent at least three times the amount of time working on side projects as I did my actual classes.
BP Gotcha, gotcha.
MK I found that just with my cohort of friends and potential colleagues as well going to university, it was the ones who actually spent time doing side projects, tinkering, breaking things, building things, that ended up with the best offers outside of university.
MA University is great, but the curriculum is probably five, six years behind, unless you're at a really good school, what actually people are doing today in software development. So it's a great place to learn the foundations, but to learn real applied skills, there's nothing better than actually building things, in my opinion.
BP Sure. Are you dunking on MIT there? That's where you went to school. They were way behind the curve? You're talking about good schools, right?
MA Oh yeah, antiquated. No, MIT is great. They definitely focus more on the basics, and you learn about assembly code and how microprocessors are constructed, and really interesting topics. Are you going to go into your job and start recreating a microprocessor? Probably not. I found it intellectually interesting, but not necessarily the most applied to what I was going to do after school.
BP Right, right. I saw a podcast that you were on called Aligning Teams with Data and Finding your Second Product/Market Fit. So are you in that mode now also, thinking about looking at the data you're getting from customers, the feedback you're getting from paid or freemium folks, and what the next turn of the wheel is, whether that's introducing a new product, a new service, or a new entrepreneurial idea?
MA So when we started session replay, which is what that DOM recreation is, that's all we did for four or five years. And that was great and got us really far, but at some point to keep growing the business we have to keep innovating and adding new functionality that customers care about and matters to them. And so since about 2018 we've been pursuing not only just session replay, but also error tracking and product analytics, which are adjacent product categories, and bringing that into one solution so that a developer and a product team can all work together and see the same single source of truth for their data and for their customer’s experience. That was a really interesting process to find what's that second and third product offering that will keep adding value to our customers.
MK So can you give a quick snapshot of where LogRocket is now and where you hope to take it in the future? Is the product, as you see it, feature complete and you’re just bug fixing and finding? Or are there still areas within that space that you want to improve on?
MA I think there's always things to do. Especially front end development is evolving so quickly that there's always new technologies and new frameworks and new paradigms to support. Where we are now is, we help you with that reactive issue, so if someone has a problem you can go see what happened to them. And also being more proactive, so what are the issues that are affecting customers and how do I get ahead of problems? Where we're investing heavily is in our machine learning capabilities. So, how do we process all this massive amounts of data so that you don't have to spend as much time in the platform to derive insights, so that you can just get a slack every morning saying, “Here's the health of your application, and here is where customers are struggling, and here's something to potentially work on.” And so we're aggressively investing in that machine learning capabilities to keep expanding the offering.
MK You've touched on this a couple of times during the podcast, the kind of ever-evolving landscape of front end development. There's a new framework every week. And so I'm curious, you support React Redux, normal JS, Next.js, and Vue. How do you go about determining where to put your resources in terms of, there's this new framework that's Svelte, or whatever it is, and we need to add that into our stack. How do you kind of evaluate these frameworks and integrate them in?
MA Good question. So for web apps, our SDK works at the DOM level, and so actually regardless of the framework you use, LogRocket will almost certainly work. And so those frameworks are more to extend further support. So for Redux for example, we can capture the actions and state over time within your application. So those integrations are more kind of further capabilities on top of the SDK. For mobile apps, which we came up with our mobile support about a year ago, those can often require different support for things like Flutter or SwiftUI or Xamarin, and so in those cases we look at really how many customers are using this, how much revenue do we think we would derive from those customers, and then see how difficult it would be for us to support, and then we do all the calculus to figure out where we should invest next.
BP So you're in the world of machine learning and trying to hire folks in that area. What do you make of the recent wave of developments and folks using these tools to help them write code or create entire applications?
MA Yeah, it's interesting. I always wonder with those types of tools, you can get 90% of the way there but how long does that last 10% take? I have a friend who is really into self-driving cars, and he was telling me in 2013, 2014, that we're going to have full self-driving by 2018, 2019. And now I'm hearing 2030 and maybe never, so I think that last mile is a really big challenge and I just am skeptical.
BP I love that analogy. I was having this discussion and it seems like there's a similar idea which is, you ask it to do something and 90% is right and 10% is wrong. Well if I ask a developer to do the same thing, how many bugs am I going to get? 90%? 95? What's their error rate and how long does it take to fix that last little bit? Maybe they're the same, maybe they're not. When it comes to driverless cars, we can't accept any margin of error. Even one crash is unacceptable. Maybe they are safer than humans, who knows? But we're not going to run that experiment. Seems like with the code it's interesting. Is a first draft from a machine learning model faster and then I go in and fix it, or is it more work? It would be better if I just do most of the writing and it fills in the blanks, the other way around.
MA And I guess that's what we see with self-driving cars. They can help you on the highway and then you need to drive outside of that. So I think that seems right, where it can do maybe 30% of the work for you, but then that last 70% is going to be probably very hard to solve in the next few years.
BP Okay, cool. Well, good luck hiring folks in machine learning. I'm sure it's a challenging gig, but maybe being on this podcast will help.
MK Matt, if there's anything else that you want to mention about LogRocket?
MA Yeah, so we have a feature on our website to try LogRocket, LogRocket.com. We also are hiring developers and so definitely visit our jobs page and reach out or reach out to me personally. But I really enjoyed the conversation today with you guys. Thanks for having me on.
BP Of course. I'm very excited to put ‘rage clicking’ in the title of a podcast. I know that's already been done but I'm going to do it again.
[music plays]
BP All right, everybody. It is that time of the show. I'm going to shout out the winner of a lifeboat badge: somebody who came on and helped to spread a little knowledge around the community. In this case, somebody found the following query: “Select * from Table 1, Table 2,” and they didn't know what this meant. They couldn't figure it out, but there is an answer now that explains what the cross join is, so thank you to Kamil for your answer, and congrats on winning a lifeboat badge. I am Ben Popper. I'm the Director of Content here at Stack Overflow. You can always find me on Twitter @BenPopper. Email us with questions or suggestions, podcast@stackoverflow.com. And if you like the show, leave us a rating and a review. It really helps.
MK And I'm Matt Kiernander. I'm a Developer Advocate here at Stack Overflow. If you want to find me online, I'm @MattKander on Twitter and YouTube.
MA I'm Matt Arbesfeld. I'm CEO and Co-founder here at LogRocket. And you can find me @M_Arbesfeld on Twitter.
BP All right, everybody. Thanks for listening and we will talk to you soon.
[outro music plays]