beeps and on-call for Next.js developers with Joey Parsons

0:00Beeps is a startup focused on building an on-call platform for Next.js. The company is grounded in the key insight that Next.js has become a dominant framework for modern development. A key motivation in leveraging Next.js is to create a developer-first experience for on-call. Joey Parsons is the founder and CEO of Beeps, and he previously founded FX, which was acquired by Figma in 2021. Joey joins the show to talk about the platform, starting a company without an explicit AI focus, the limitations of current on-call systems, building on Next.js, and more. This episode is hosted by Sean Falconer.

0:38Check the show notes for more information on Sean's work and where to find him.

0:54Joey, welcome to the show. Hey, thanks, Sean. Great to be here. Yeah, absolutely. So you're the founder and CEO of Beeps. Tell me about the company. What's the vision? Where are you guys at today? Yeah. So Beeps is sort of like an on-call platform built for modern developers. And when I say modern developers right now, like the area that we're focusing on is Next.js developers, right? What we've seen, you know, if you go to product hunt or hacker news on sort of like a day-to-day basis, they are, you know, probably like 60 to 70 % of like the companies that are being launched today are being actually launched on this platform.

1:29So they're Next.js developers building on top of Rissell. And they actually have very unique challenges when it comes to infrastructure. So Geeks is an on-call platform that's being rethought from the ground up with, for now, the needs of this developer. So it's been pretty fun to build. We're about a year into it right now. Just launched our platform, and it's a pretty exciting time. Yeah. I mean, I guess given that you're seeing that kind of trend with Next.js and Vursell, I guess that's, you know, good job Vursell and the team over there. I mean, that's a good sign that they're doing well. So, and this is not your first company, right?

2:06You've founded companies in the past and you were on actually, you know, talking to Jeff in the past on here about a prior venture. Like, I guess like why put yourself through this pain over and over again? Yeah, yeah. It's an interesting sort of like origin story. So I guess to rewind a little bit, I've been in tech, but largely in sort of like the infrastructure and reliability side of things for a little over 25 years now. Like a lot of people these days might not know Rackspace, but they were one of the early sort of like hosting companies, like one of the precursors to like, you know, Amazon's and like the whole cloud today.

2:37And I was actually in like probably like the first hundred employees there. So like way back in the early aughts and got to sort of see sort of like at that point, how companies were building sort of like globally performant, globally reliable, like platforms at scale. And was lucky enough to be able to sort of like really build a career and an expertise around this. I guess most notably, I ran reliability in a large part of like the infrastructure team at Airbnb for a handful of years and got to see sort of like the evolution of like infrastructure from that perspective. And then, as you mentioned, after that, I left to start a company called FX, which is more of tracking microservices.

3:11Start a company. We were acquired by Figma in 2021. And I spent a year and a half there working on developer productivity. Again, restarting, thinking about reliability. So when I left Figma, I started thinking about the next thing. A lot of people were like, yeah, why would you put yourself through the pain of starting another company and going down this journey? And it's just, on-call has been such a big part of my life. Like reliability has been such a big part of what I've built my career around. And if you look at sort of maybe the last 10, 15 years of like software development, everything that an engineer does on a day-to-day basis has gotten exponentially better, especially in like the last two to three years.

3:48And, you know, whether it's like writing code, testing code, deploying code, like observing code and production, right? All of it's just worlds better than it was, you know, at the advent of like mobile and cloud. But the one thing that literally hasn't changed is on-call, right? There's been a handful of companies that have dominated in the space. And they've built great brands and great trust out there. But nothing has really evolved in the way that actually is looking out for the engineers that are on-call or just kind of making this process better. So, you know, having been through this for such a long time and, you know, been had the weight of deck of corns on my shoulders in the middle of the night and sometimes, you know, being on call for like early stage startups where like I'm literally the only person on call for like months on end.

4:30I'm pretty sure it's taken its toll on me. And I think that I feel kind of like obligated to make this better for like the next generation and at least try to like drastically improve this experience. So, yeah, I think it's a worthwhile endeavor. You know, the fact that you're on call for other people's on call is a little bit crazy. It makes it a little bit different than what a traditional startup would be. But I think, you know, if we can really crack this, then I think that it's going to be worth it in the end. So yeah, I always say during, I founded a company years ago, and I would say I was on call for seven years, basically during that time.

5:01And it's a lot, you know, it's stressful. And I want to get into some of this sort of downside of existing on call today. But before I get there, you know, one other question I had regarding, you know, starting a company, especially right now, like, have you found this time around that? Given that we're sort of in this like AI hype boom, it's kind of hard to start a company that's not focused on AI right now. Like, you know, when I was doing my company back in like 2009, 2010, like everything was about social. And, you know, people would always ask like, you know, what's your viral strategy or what's your social strategy?

5:34And there was all this pressure to do stuff that wasn't necessarily like core to the product, just to have a story around it to tell like investors and stuff like that. So I guess like, and then when these hype cycles are coming on and you're doing something different, it's like hard to sort of bust through the noise when everybody's like paying attention to this one thing. So I'm curious about your experience there. Yeah, I think it is a little bit funny. I think like when I was sharing sort of like the vision for beeps with one of our investors, like, you know, halfway through the conversation, someone interjected and was like, oh, this is the longest we've gone without ever hearing AI in a pitch.

6:05And this was like last year. So I think it's an interesting time. I think that one of the challenges I see these sort of days is folks are so much more fixated on technology than they are actually the problems. And we actually are heavy users of LLMs at Beeps, both for our own development and in Beeps itself. There's a bunch of stuff that's powered by AI, but we actually don't talk about it. Because we're much more focused on the problems and our users care about the applicability of it, much more so than they do the actual technology that drives them. And that's always been the case. Right. But it's not to say that it doesn't get folks excited.

6:40It doesn't get folks ready that they're using to be able to tell people and their peer group or their company that these AI products are making them better. So, yeah, it's an interesting space out there. I think, you know, in some companies that are like relatively in the same space as us, seeing sort of like the seed round that they're raising are pretty astronomical and like the, you know, the tens of millions and things like that. But ultimately, it's going to come down to who builds the most value for their users and regardless of the amount of money that they raised. And we'll see how that shakes out in a long time.

7:12But to me, it's actually like a really exciting time to build a company. It's a really exciting time to be an engineer, like a developer, building products and getting to try a bunch of these tools and seeing how quickly they're evolving and how quickly they're getting better. It's like, you know, every few weeks, my team's asking about some new IDE that they want to try out. and they love it more than the last one. It's just like, okay, when is this going to stop? But at the same time, if it keeps unlocking a lot of potential there, then that's a really great thing. So a pretty long-winded answer there, but I think that's kind of how I've been thinking about it and how it's kind of played out for us.

7:44Yeah, I think we'll kind of know that we're out of the hype cycle when I think companies do go back to somewhere more focusing on sort of the value of what they provide versus the technology that's behind the value, right? It's like when a company can essentially talk about like, hey, we can solve this problem for you. And that's really what the buyer cares about. But maybe there is AI that's powering that plus a lot of other stuff, right? But it becomes less of like, it's in the essentially title of the company's name. Yeah. Yeah. So many people are launching on.ai domains. I don't blame them, but it does kind of, I think it pigeonholes you a little bit in terms of like the solution that you're providing.

8:25But it's a tricky thing. I think it makes sense in this moment. And I guess we'll see how it plays out over time. So back to on-call, what does that on-call process look like for most companies? Yeah, it's kind of growing, right? Or it's kind of evolving, right? Traditionally, most companies have a very simple rotation, whether that is across one team or a bunch of different teams where you have basically your primary on-call. It's like the first person that's getting notified. You have a secondary. And then, you know, sometimes you might have like a manager is like your tertiary on call, you hook up your observability system.

8:59So this sort of like platform. So it ends up sort of like being like a routing layer for who gets notified when something breaks. And for most companies, it's just that, right? And I think that it's a, you know, a pretty standard thing at most companies, once you reach some semblance of product market fit, or you have users that actually matter. and one of the things that's like the companies that have been around for a long time they do this really well like pager duty for example right like their cto tim says all the time right like nobody ever gets fired for choosing pager duty right and i think that it's a powerful thing but they've dominated the market simply based off that brand right and that trust and that reliability and even someone that has run reliability at a company like airbnb or figma I know I can't easily just walk in there and say like, hey, like I helped build this team, right?

9:47Like use my new product. We just don't have that sort of like credibility. And I definitely understand that. So it's like, there's definitely like the technology piece of this, but there's also sort of like the brand building over time. That's going to really matter to be able to kind of like win over the hearts of developers and be that recognizable name that when they begin to feel that fit, when they have those users that matter, they ultimately sort of like have an option to choose there. But it's the most interesting thing about sort of the Next.js space and the Vercel space is that folks are willing to try and actually want to try sort of like modern tools that are tailor-made for that.

10:19Right. If you look at sort of, you know, they're choosing to host on Vercel and Fly.io instead of like running their own infrastructure on top of AWS, instead of rolling their own authentication systems or using sort of like older solutions like an Auth0, a lot of them are choosing to use Clerk or use like SuperBitsSauce instead of like running your own databases. So there's a sort of like passionate community that have all these different new problems, these new challenges, and they're willing to make bets on like earlier companies and kind of ride the wave with them. And they have unique challenges, unique things that we need to think about for how we deliver sort of a platform that helps them while they're on call.

10:55And that's sort of like the path that we're going. And I can get into that a little bit more. Yeah. How did you come to sort of recognize that, you know, the subset of perhaps the Next.js community was sort of the ideal customer profile for you guys? they're open to using these various managed services. They're sort of on the forefront of the technology adoption curve. Like, how did you kind of, you know, I guess like stumble into recognizing that this is probably like a good spot for us to actually go to market with? Yeah, I guess, I mean, like pretty simple answer, just kind of like as a developer myself, when I started hacking on things, I was using like the Next.js tool chain, right?

11:31Like it was just really simple for me to kind of get going, right? And then you look at like the credibility of the companies that have kind of like grown up on those platforms over time. It really reminded me of sort of like the late movement of like the, you know, 2008 or like the late 2000s, where people were choosing like Ruby on Rails, running Django, right? And then you have companies that like Airbnb and GitHub that were built on top of like Ruby on Rails. I think that same sort of movement has been happening over the last few years in the space. And if you look at like tutorials to get started on building a new app, right?

12:00Back then it was like, you know, how do you get started with Rails? It's like how Mongo really kind of got going, by really targeting the Node.js space. But now it's everything out there in terms of how to get going, what people are live streaming on Twitch and what a bunch of YouTube videos are for getting started with building a web app. It's all Next.js. So a lot of it was personal experience. A lot of it was just what you're seeing in the community and the excitement about it. If you go to Twitter and people are talking about it's really popular to have that list of like, oh, what's my tech stack in 2024?

12:33You look at those things And one of the leading things on there is probably Next.js. And it just became really obvious to us. And in terms of the existing on-call systems, what are some of the problems with the current approach? It hasn't evolved, sure. But why is that a problem, I guess, for companies? Yeah. I guess I'll take my time back to some of the companies where we build reliability and things like that. So a lot of the times, these companies do a great job of notifying you. Right. Like whether it's like a push notification or SMS, but it would just kind of drop there. And what engineers actually need are sort of like the rituals around on call, as well as like the things that actually help them during an incident.

13:14So if you break it up like incident management, like there's all the things that, you know, you do before an incident happens to make yourself resilient to them. There's everything that happens during an incident, right? Like getting the context to understand sort of like what's happening. And then after an incident, there's like all the stuff that you do to sort of like follow up with whether it's like incident reviews or postmortems to kind of get going. And every company at some level of scale that has things that matter ends up building a lot of like the tooling around the existing sort of like on-call solution.

13:44And a lot of it's, you know, very similar. Like a lot of people ended up following the Google SRE sort of like handbook, that book that was released, what was this, like 10 years ago, I think at this point. And have, you know, we're really focused on building those processes. And it was kind of strange that some of these incumbents didn't take the ball in front of them and didn't build anything to actually improve the full on-call lifecycle there. So I think that with Beeps, one of the things that we're really focused on is helping engineers build context when something bad happens. So one of the key features in our free product is that we work with a handful of the modern observability tools that folks are using in this space.

14:26So your highlights, your axioms, your sentries. Sentries has been around for a while, but they've kind of like the preemitted error tracking tool in this space. And what happens is most folks, especially at the early stage and as they begin to grow, they just have these alerts sort of piped into Slack. So let's say you have an exception being triggered or a notification coming from Axiom about some trend that's happening in logs. You'll get this nicely printed out sort of message there. and our sort of like our assistant in Slack will actually like listen for these messages and knows how to pull context out of them.

15:01So let's say you get something about like your users aren't being able to log in, right? Like something's triggered in Axiom where you've set up alert that happens. We'll automatically listen for that and immediately begin a thread to help you understand context. So if I rewind a little bit, what most happens, let's say I get, you know, you probably experienced this having been on call for like years on end is that, you know, the first thing you do is you probably open up a handful of tabs in your browser, right? You're looking at, okay, what got deployed recently? What were some of the commits in those deploys?

15:31Like, are there any like services that I use that are down or any servers down, right? What are the most recent logs for my application? And there's kind of like this playbook that you're running through every single time, just to kind of get context to like eliminate potential factors to make you understand where you're going to go do next. And depending on like the experience level of the engineer that's responding to this, you may or may not do these things. you may miss some information that should have just been an obvious thing to look at. And that's really hard when you're woken up at 3 o 'clock in the morning to remember to do all these things and remember which places to look.

16:03And it's a time-consuming process, right? You're navigating all of these different user interfaces that aren't consistent, may change. The runbook's usually kind of outdated when it comes to this sort of stuff. So instead of taking the 10 minutes to do that, we'll actually get all that information for you and print it for you there nicely in Slack in less than 20 seconds. So imagine being woken up at 3 o 'clock in the morning by a notification. Instead of the X amount of minutes that would take you to get to that context, you could, in your bed, understand what you're going to do next when you wake up and get to that context really quickly.

16:36So we hooked into all the different systems in this for-sell Next.js ecosystem really well. I'd have been able to build some really tight integrations to be able to build that context really quickly. So we think that that is going to be a really great lever for people to reduce the amount of time that it takes them to understand the problem, which then in turn helps them understand how to fix it faster. Can you walk me through, you know, what's actually happening in the software behind the scenes when NMRT comes in in order to build that context? Like, how are you actually going and essentially pulling in the right data from all these different places?

17:09How's the integration work and so on? Yeah, yeah. So one of the things that we really tap with beef is that you can get started in literally like minutes, right? So, you know, we just have, you know, simple integrations with Vercel. where most people are hosting their apps, a simple integration with GitHub, and then a simpler integration with Slack. You actually don't need to configure beeps to talk to Century or Axiom or Highlight. We've done all that hard work for you. So through the Vercel API, we're able to grab a lot of really great and rich information about your app, about its deployments.

17:37We have read-only access to your code base to understand the different providers that you knew. So we'll look at things like your package JSON to see the packages that are related to maybe a clerk or a super base and things like that. And then when our assistant is listening for messages in a Slack channel that you direct us to, and we actually will work with any sort of tool that is observability-based, that's setting alerts there. It doesn't have to be Century, Axiom, or Highlight. It'd even work with a data dog where we are looking at the messages and using an LLM to basically decide whether or not this is actually an alert coming in from an observability provider.

18:17And then at that point, we kick off the investigation process across a handful of agents in the background that understand we have a different tool for every integration that basically will go out and fetch this information, send that back up to the primary agent that's communicating through Slack. And then it uses that information to decide what it wants to share, what's the most important context based on the alert that came in to help the user understand what to do next. So again, the background a lot is AI and LLM-based when it comes to the prop moments. It's much more streamlined than that, but it gives us some flexibility to be able to not just give a static list of information back, but actually have context based on the alert that came in.

19:01Yeah. And then you can take advantage of some of the things that these AI tools are really good at, like summarizing information, essentially. Exactly. Exactly. In terms of the context, how do you test that the context that you're providing is actually valuable in the right context? It's a lot. I guess this is probably one of the hardest things to do right now. Obviously, we've written a bunch of tests ourselves that provide inputs. And based on the prompts that we have in the context that we pass those prompts, are we getting information back? And then at the same time, we have a bunch of test apps running wild in production that actually get real traffic and actually have real issues.

19:45And that's probably the best way to test that, okay, was this actually valuable to me? And one of the things that we do at Beeps is that we actually ask you afterwards, was the context that we provided useful to you? And we're using that to power a lot more stuff in the future. I think that there's definitely like a world where as we're able to provide better answers that might give you a hint about what to do next, being able to push that into a direction where eventually a user will have enough trust with what solution we're providing to where maybe they would hand the keys over to us and say, go fix this automatically.

20:22And I think that while I don't think we're there yet, and there's a lot of scar tissue with the whole AI apps promise over the last 10 years, I think there's a world where this could get to the point where there's a large share of issues that are relatively common across a code base that could be solved without human interaction. And hopefully we get there because that's one of the ways you make on-call drastically better. Yeah. I mean, even if you can get to a place where you can provide through an assistive technology, like a pretty accurate depiction of what the solution should be, that's massively more useful than like, hey, here's an alert.

20:59Like there's a problem. Go figure out the problem and the solution. Yeah. And we're very keen on like being suggestive and not sort of like promising the world on this sort of stuff. I think that like, you know, there's other companies in the space that kind of promise sort of like the world when it comes to that sort of stuff. And it's a different game than sort of like your co-pilots of the world that are helping you code, right? Like incident response is very high stakes. And again, like trust really matters here. So we'll see if they're able to have success by doing that. But I think, you know, it's one of those things where if you give someone the wrong answer and you give it to them with a lot of confidence, you can lead someone down a bad path that could have detrimental effects for their users and their company.

21:38And that's a big bet to make at this stage. So yeah, I mean, I think one of the biggest challenges with LLMs is that they're like inherently, in some ways, like the worst form of employee where they're like overconfident and incompetent at the same time. It's like very sure of themselves. Here's the wrong answer. Yeah, yeah. And then obviously that'll improve like over time, right? Like I think we'll get to where that maybe they're not as incompetent as the worst employee. But yeah, we're definitely not there yet, especially when it comes to solving some of these like tricky novel problems. How do we get to a place with on-call where you're not sort of bombarded by the noise of everything and you only have to deal with more, you know, essentially novel issues?

22:19Yeah, I think this is, you know, at least my opinion is that this is sort of like the path to get there. You know, what you don't want to have, you're sort of exactly right, is, you know, like so much of on-call, at least from what I've seen, is just kind of you're getting through the muck of the annoying sort of repetitive things, the things that happen like once a week that aren't actionable, that almost like really ruin the experience for you. And then when something novel does happen, you're too tired or you've been wrecked for like the last few days by these sort of like pestering alerts.

22:50And I think that the process that happens outside of on-call is really important there. And I think the on-call tool actually has a lot of influence on that. And the idea of sort of what happens in larger organizations, even smaller companies, is that you have these handoffs that may lead to action items of things to go look at and things to fix as a result of that. But it's a very human process. It's a ritual that happens maybe not very consistently. And the great thing is that with LLMs and some of these tools, you can power a lot of that. You know the history of alerts that happen. You know that they've happened at some level of frequency.