Shawn Falconer (4:52)

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. And 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 my 2009, 2010, like, everything was about social and people would always ask, what's your viral strategy or what's your social strategy? And there's all this pressure to do stuff that wasn't necessarily core to the product, just to have a story around it to tell investors and stuff like that. And then when these hype cycles are coming on and you're doing something different, it's hard to sort of bust through the noise when everybody's paying attention to this one thing. So I'm curious about your experience there.

Joey Parsons (5:52)

Yeah, I think it is a little bit funny. I think when I was sharing sort of like the vision for Peeps with one of our investors, you know, halfway through the conversation, someone interjected, it's like, oh, this is the longest we've gone without ever hearing AI in a pitch. And this was like last year. So I think it's an interesting time. I think that, like, you know, one of the challenges I see, like these sort of days is like, folks are so much more fixated on technology than they are actually the problems. Right. And, you know, we actually are like 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. Right. Like, it's because we're much more focused on the problems and our users care about like, the applicability of it much more so than they do the actual, like the technology that drives. And that's always been the case. Right. But it's not to say that it doesn't get folks excited, it doesn't get folks, you know, ready that like, they're using to be able to tell people in like, their peer group or like their company that, you know, these AI products are making them better. So, yeah, it's an interesting space out there. Like, 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 like 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. But 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 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 like, they love it more than like the last one. Just like, okay, when is this going to stop? But at the same time, if it keeps unlocking like a lot of potential there, then that's a really great thing. So 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.

Shawn Falconer (7:44)

Yeah, I think, like, 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 like, 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.

Joey Parsons (8:14)

Yeah, yeah, yeah, yeah. So many people are like, launching on AI domains and 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. But 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.

Shawn Falconer (8:29)

Yeah. So back to on call, like what does that on call process look like for most companies?

Joey Parsons (8:36)

Yeah, it's kind of growing, right. Or it's kind of evolving. Right. You know, traditionally like most companies have sort of like a very simple rotation, whether that is across like, like one team or a bunch of different teams where you have, you know, basically like your primary on call. It's like the first person that's getting notified, you have secondary and then you know, sometimes you might have like a manager as like your tertiary on call. You hook up your observability systems to 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, 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 PagerDuty for example, right? Like their CTO Tim says all the time, right. Like nobody ever gets fired for choosing PagerDuty. 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? Like 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. Right. 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, Supabait Sauce instead of, like, run your own databases, you know, so there's this sort of, like, passionate community that have all these different new problems and these new challenges, and they're willing to make bets on, like, earlier companies and kind of ride the wave with them. And. 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. And that's sort of like the path that we're going. And I can. I can get into that a little more.

Shawn Falconer (10:58)

Yeah. How did you come to sort of recognize that, you know, this subset of perhaps the next JS community was sort of the ideal customer profile for you guys? You know, 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?

Joey Parsons (11:22)

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 toolchain, right? Like, 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 and 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 this space. And if you look at, like, tutorials to get started on building a new app, right back 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, like, the Node JS space. But now it's kind of like, everything out there in terms of, like, how to get going, what people are, like, live streaming on Twitch and what a bunch of YouTube videos are for, like, getting started with, like, building a web app. It's all next js. So, you know, a lot of it was personal experience. A lot of it was just kind of like what you're seeing in community and the excitement about it. And you know, like, if you go to Twitter and people are talking about, you know, it's really popular to have like that list of like, oh, like, what's my tech stack in 2024? Right. It's, you know, you look at those things and you know, like one of the leading things on there is probably like next js and you know, it just became really obvious to us and.

Shawn Falconer (12:40)

In terms of like the, you know, existing sort of on call systems, like, what are some of the problems with the current approach? Like, hasn't evolved. Sure. But like, yeah, why is that a problem? I guess for companies.

Joey Parsons (12:53)

Yeah, like if, you know, I guess I'll take my time back to like some of the companies where we build like reliability and things like that. So a lot of the times, you know, these companies do a great job of like notifying you, right. Like whether it's through 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. So 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. And a lot of it's, you know, very similar. Like a lot of people ended up following the Google SRE Handbook. That book that was released 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, you know, some of these incumbents didn't take the ball and run with it, right. And didn't build sort of like anything to actually improve the full sort of like on call life cycle there. So I think that, you know, with beaps, one of the things that we're really focused on is, you know, helping engineers sort of like build context when Something bad happens. So one of the key features in our free product is that, you know, we work with a handful of like the modern sort of observability tools that folks are using in this space. So you're like highlights your axioms, your sentries. Like sentries been around for a while, but they kind of like the preeminent sort of like, like 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 like typed in the Slack. So let's say you have an exception being triggered or like a notification coming from Axiom about some trend that's happening in logs. You know, you'll get this, you know, nicely printed out sort of like 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. So 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, will 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 a 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? Like, 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, like when you're woken up at like 3:00 in the morning to remember to do all these things and remember which places to look. And it's a time consuming process, right? You're navigating all of these different user interfaces that aren't consistent, may change. You know, the runbook's usually kind of outdated when it comes to sort of stuff. So instead of like 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, you know, the X amount of minutes that would take you to get to that context, you could like in your bed, understand what you're going to do next when you wake up and get to that context really quickly. So we hooked into all the different systems in this Vercel Next JS ecosystem really well and have been able to build some like, you know, really tight integrations to be able to build that context really quickly. So we think that that is like going to be a really great lever for people to reduce the amount of time that it takes them to understand a problem, which then in turn helps them understand how to fix it faster.

Shawn Falconer (16:57)

Can you walk me through what's actually happening in the software behind the scenes when an alert 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. How's the integration work and so on.

Joey Parsons (17:11)

Yeah, yeah. So one of the things that we really tag with beeps is that you can get started in literally like minutes. Right. So you know, we just have simple integrations with Vercel, where most people are hosting their apps, a simple integration with GitHub and then a simpler iteration with Slack. Right. Like you actually don't need to configure beeps to talk to like Sentry or Axiom or Highlight. We've done all that hard work for you. So, you know, through the Vercel API, we're able to grab a lot of really great enriched information about your app, about its deployments. We have read only access to your code base to understand sort of like the different providers that you use. So we'll look at things like your package JSON to see sort of like the packages that are related to like maybe like a Clerk or like a Supabase and things like that. And then when our assistant is listening for messages in a Slack channel that you kind of like direct us to and you know, we actually will work with any sort of tool that is observability based that's setting alerts there. Like it doesn't have to be Sentry, Axiom or Highlight. It even work with like a data dog where we are looking at the messages and using an LLM to basically decide whether or not this is actually like an alert coming in from like an observability proposal provider. And then at that point we kick off sort of like the investigation process across, like, a handful of, like, agents in the background that understand sort of like, you know, we have a different tool for every integration that basically will go out and fetch this information, send that back out to sort of like the primary agent that's communicating through Slack, and then it uses that information to decide what it wants to share. Like, what's the most important context based on the alert that came in to help the user understand what to do next. So again, right, like, the background a lot is like, AI and like LLM based when it comes to, like, the problem, it's much more streamlined than that, but it gives us some flexibility to be able to, you know, not just give a static list of information back, but actually have context based on, like, the alert that came in.

Shawn Falconer (19:01)

Yeah. And then you can take advantage of some of the things that, like, these AI tools are really good at, like summarizing information essentially.

Joey Parsons (19:08)

Exactly. Exactly.

Shawn Falconer (19:10)

In terms of the context. Like, how do you test that the context that you're providing is actually valuable in the right context?

Joey Parsons (19:17)

It's a lot. It's like, this is, I guess, you know, this is probably one of the hardest things, hardest things to do right now. Like, obviously we've written a bunch of, you know, kind of like tests ourselves that provide inputs and based on sort of like the prompts that we have in the context that we pass this prompts, you know, are we getting sort of like information back? And then at the same time, you know, we have a bunch of, like, test apps running wild in production that actually get, like, real traffic and actually have real issues. And that's probably like, the best way to kind of test that. Like, okay, was this actually, like, valuable to me? And one of the things that we do with beeps is that we actually ask you afterwards, like, was the context that we provided, like, useful to you? And, you know, 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. Right. And I think that while I don't think we're there yet and there's a lot of, like, scar tissue with like, the whole AIOps promise over like 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.

Shawn Falconer (20:44)

Yeah, I mean, even if you 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 hey, here's an alert, there's a problem. Go figure out the problem and the solution essentially.

Joey Parsons (21:02)

Right, yeah. And we're very keen on being suggestive and not promising the world on this sort of stuff. I think that there's other companies in the space that kind of promise sort of 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 could lead someone down a bad path that could have detrimental effects for their users and their company. And that's a big bet to make at this stage.

Shawn Falconer (21:39)

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 an employee, where they're like overconfident and incompetent at the same time, very sure of themselves. Here's the wrong answer.

Joey Parsons (21:55)

Yeah, yeah. And 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.

Shawn Falconer (22:09)

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?

Joey Parsons (22:19)

Yeah, 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 is 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, you know, too tired or you've been wrecked for like the last few days by these sort of like pestering alerts. And 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 or even smaller companies is that you have sort of like these handoffs that may lead to like, action items of like, things to go look at and things to fix as a result of that. But it's a very like human process, right? It's a ritual that happens maybe not very consistently. And the great thing is that with LLMs and some of these tools is like, you can power a lot of that, right? Like, you know, the history of alerts that happen, you know that they've happened at some level of frequency. You know, that, that, you know that one alert has come in every Wednesday night at midnight utc and you know, being able to sort of like track that and understand like what to do about it and what's noisy and what's not, there's an obligation, I think, as an on call provider to provide that information and make it easy to digest and easy not have to be like a human process on the outside. And I think that's how you build continuous improvement into this process. Another thing that we kind of have a hot take on is the concept of incident reviews and postmortems. You know, like at a lot of companies this ends up being a lot of theater, I think. And you know, there's probably a whole group of like people that, you know, learn from incidents that are going to come after this. But I think that that's one of the things that we definitely want to improve upon. Because what an engineer really needs is not a document that they're not going to ever read again that, you know, has a lot of really great information about it, but it's like surrounded by prose that they have to read through in sort of like a thick moment. What they really need is that context when it happens again, right? Like what, what is the evidence of this incident happening in the, in the past? You know, what is the historical context here? How is it resolved last time? What are the different things to try? And I think that a lot of that could be actually like auto generated and provided at the moment something critical happens and provide that context that instead of again this other document that you know, was discussed and learned from, which is, which is obviously great. A lot of folks probably aren't going to remember that when the world's crashing around them and they've got to solve this issue. So it's a tricky thing and we really want to make that better. And I think a lot of these rituals that happen outside of actually being on call are one of the best places for, you know, helping an engineer have confidence, have context and you know, be able to walk into a very novel situation, understand history and make it better. But I think you're right. Like the first thing is just really getting rid of like the noise, eliminating the non novel things from having to be resolved by a human and then sort of taking it there. But we are ways away from that, just to be honest. Right. Like it's a, you know, that's something that we want to build into. I'm sure there's other folks building into this as well, but I think that there's a, there's a big problem to be solved there and, but it's an evolution.

Shawn Falconer (25:39)

So yeah, for where the product is today. Do you see the main value proposition for an organization using BEAPS is around just like saving time. Like saving essentially like engineer is probably one of your highest cost. Like employee resources within a company like this is a way to essentially reduce the, you know, cost where they're maybe not building essentially, you know, core product.

Joey Parsons (26:01)

Yeah. Like as a CEO myself and having been like an like a leader of, you know, large engineering teams, there's three things that I've always wanted, right. You want your engineers to have all the tools that they need to be productive, but you want them building products, right. Like a lot of times you don't want them focus on like infrastructure and reliability. Like I'm sure every CEO dreams that they can have an engineering team that instead of dealing with like tech debt and like incidents and things like that, they wish that they were all building product and building value for users. So the more that you can sort of like eliminate there, the better. And then obviously like number two is like you want to have a fast, reliable, secure product. Right. So making sure that you know, you can sort of like meet the expectations of your users and terrible things not happen is vastly important. And then you want to have like a, a really like happy, engaged team that cares about its users, that cares about a product. Right. It's like usually at the, the top three things that you want as an engineering leader or even a CEO when it comes to thinking about engineering and on call touches, all those things, right? It's like, you know, it really impacts people on the weeks that they're on call, if they've had like, bad experiences. And, you know, every minute matters for your users when it, when it comes to building something that's actually meaningful. And we're past the days where, you know, you can have like, like a 9 to 5 on call because your, your business is predominantly like in the United States or like regional. Like, everybody's got, you know, global customers that, that care and matter. And having a team that being, that's being able to support that is like, is really important and I guess kind of to take another step back. One of the other things that we're seeing is, I even saw this at like, Airbnb and figma, is that we're moving past a world where were like, people like me were the ones on call, the ones that grew up in like, from sysadmin to ops to like, sre. I guess people are calling it like, platform now, right? Where you have these highly trained engineers that have like, a compendium of shit in their brain that they've been through, right? Like, they, they know how to deal with these things. Like, they recognize what, you know, database instability looks like really quickly. They recognize. They know how to, like, sift through a bunch of graphs and build context. They can see a wall of logs and immediately recognize things. Companies are relying a little bit less on those going forward, right? Like, especially in this sort of like, next JS space, people are growing up. There's just not a lot of, a lot of need for that. And even at companies that are built on top of the cloud and built on top of a bunch of these other providers, you're moving less and less to where you have these, like, highly trained folks that have been in this for a while that recognize these patterns really well as the folks who are on call. And instead you have, you know, just software engineers on every team, regardless of experience, sort of taking this burden on. So, you know, you have new grads, like, you know, six months out of college, and they're being woken up in the middle of the night to solve these really hairy issues. And, you know, they're just not like, super, super confident about it. So one of the things that we're very prescient about is like, we're building for these developers, right? We want to be able to, like, we're focusing specifically on their needs. How do, how do we. How do we help build that confidence? How do we help Build that context and building a tool and a platform that. That does that.

Shawn Falconer (29:10)

So in my experience, like when I was at my time at Google, when you had Super Junior people on call, you know, it's a learning experience for them, but it ends up actually being like, creating more work essentially for everybody else because there's just not that much stuff that they can actually handle on their own. So they end up sort of almost like a proxy or relay to the more informed people on the team that need to actually jump in there and like, actually solve our problem.

Joey Parsons (29:35)

Yeah, yeah. So, like, imagine if we could just make that better, right? Imagine if those engineers, again, like, going back to, like, opening up the different tabs in your browser, right? Like, they could just not be getting all of that context because they just don't have it ingrained that these are the different places to look and these are the different tools I need to look at. And instead, if we can just give you that context and immediately, you know, if it's like, you know, if it's like a recent code change and you can just roll back really quickly, that's a huge win for most companies. And going back to, like, the other big. The other big sort of like value of beeps right now. And what we're really providing is that one of the things that's very distinct in this space that we're building in is that a lot of times you're not thinking about servers anymore. You're not thinking about servers, but you're thinking about services, right? You're thinking about these different APIs. So you look at, like, again, going back and using the example of, like, Clerk and Supabase for off and like, Neon, planetscale and other places for your database, and using tools like resend for email. And, you know, a lot of these companies that are building on top of like, LLMs, they're, you know, they're talking to Anthropic, they're Talking to Open, OpenAI, Grok, all these different providers. And one of the challenges they have is like, when sometimes when your app breaks, you don't know if it's you or if it's them, right? Like, you don't know if, like, they're down or if they're actually having issues. So one of the big values that we provide is that we keep track of the different providers that you use. So anytime, like your package JSON changes or some of the other signals that we look for in your application code base, we update the list of providers that you use, and we have a pretty Comprehensive list of all the different tools that folks use in this space. And anytime they go down, we let you know a lot of times, like within like a handful of seconds. So you immediately have that context, you know why they're down, and can make decisions appropriately based on that. And it's just a. It's a pretty simple thing, but it actually provides an absolute ton of value because again, it's not something you have to go look at. You don't have to keep track of the status of, you know, the 16 different providers that you use. And we do that for you and not only tell you when they're down, but, like, when you're down, we'll actually tell you if it's you or it's them. It eliminates like a big source of anxiety that engineers in the space have been, have been dealing with for a while. We did a cheeky thing where we're like, you know, Vercel has been, you know, they had like, are we Turbo yet? And some of these things to track sort of like the, the status of their different, like, big initiatives. And I was sitting at Next JS Conf, like it was like last year and they were talking about are we turbo yet? And I went out and bought are we down yet? And we have a sort of like, portal where you can see sort of like the, the last time an issue was reported on any of these big providers. It's pretty interesting to see like, who's down all the time and who's not. And it's kind of like an honest look at this industry and some of the tools that they use. And hopefully we can help promote better reliability in the space and help this ecosystem grow in a more like, you know, grow in a more solid way with a lot of this data. And we're going to be ramping that, revamping that up a little bit more to maybe, to maybe show some comparisons between different tools and, and things like that. But it ends up being a big value to our users. And one of the things we're really excited about, it's just, just knowing that.

Shawn Falconer (32:39)

Simple information in terms of the engineering of beeps, what's the stack look like?

Joey Parsons (32:45)

Yeah, so we're 100% TypeScript. We want to feel the pain of our users. And predominantly our web properties are all Next js, Right. So again, completely dogfooding the system that we're building for. And then we have a bunch of TypeScript services running on the backend using Node JS and basically running on a handful of like, you Know, platforms that make it really easy to run containers, like Fly is one, one, one example there. And you know, it's pretty simple stuff, but, you know, I think in order to really build and understand sort of like the challenges that are, that our users have. Right. It was important for us to, to build, to build in this space as well. Obviously, like, you know, when we're measuring the health of all these providers, we can't use all of them. Right. Because we don't want. We like, beep seems to be more reliable than sort of like even the systems that, that we're monitoring or the systems that our users are managing. So it's a pretty fun challenge. But again, just like pure typescript at.

Shawn Falconer (33:42)

This point in terms of deployment, then this is run as essentially like SaaS.

Joey Parsons (33:48)

It is run as a SaaS. Yeah. So we have our web app that, you know, is used for like, setting up integrations, getting information about like, the different apps and sort of like the history. We have a whole status page product where as part of like our free product, you get a status page where you can, you know, communicate status of your application to your users. Right. And we have a bunch of different themes that are sort of like, fun for this sort of like community. And it's a good way of like expressing your brand through our themes. And yeah, again, those are all just kind of like, like web properties.

Shawn Falconer (34:19)

And then, yeah, in terms of what you're doing with some of the LLM work, like, how do you manage orchestration? Like, I think you mentioned that you have like a number of agents that are going off and performing, you know, independent work. Like, how does that workflow work? Is that something that you built in house? Are you using some sort of framework for that?

Joey Parsons (34:38)

Pretty much. We've built that all in house. A lot of like the agentic frameworks out there, like a lot of them are like written in Python and just not sort of like matched up to our stack. And you know, whether or not like those agentic frameworks have like a shared consciousness or each agent has like its own consciousness was some of the things. So like we went out and built like our own internal package in TypeScript ourselves that, that we're using, I think it might be something that we eventually open source because from like a TypeScript perspective, there's just not a lot out there to be able to build these tools. And I think that it's something that I think that we could contribute back. We probably need to do a lot of cleanup and not be so beep specific. But I think there's a world where we hope to be able to share that out with the world and you know, help that community sort of grow.

Shawn Falconer (35:20)

So yeah, yeah, I've heard that is a consistent issue with a lot of the like, not just even agent frameworks, but essentially like all the sort of libraries are available. Like they're. If they're not Python, solely Python, they're Python heavy where their support for other languages is not as well documented and there's less of a community behind it. So it's kind of hard to like invest you know, company resources in a framework that maybe not be there in like six months from now.

Joey Parsons (35:46)

Yeah, like, but we found that like we originally built some of our own, like our own SDK to interact with the LLMs to basically do sort of like failover and like racing between, you know, like anthropic or like, or like OpenAI and so that we could be resilient to sort of, sort of like any sort of failures there. But the Vercel AI SDK is actually like pretty, pretty solid when it comes to this stuff and we recently switched over to that to power, sort of like our connectivity to like LLMs. But you know, it's starting to catch up a little bit. But yeah, from like an agentic framework sort of perspective it's, it's just not, hasn't, hasn't sort of like reached that level yet.

Shawn Falconer (36:23)

Are you also using D0 from Vercel?

Joey Parsons (36:26)

I do a little bit of it, yeah. We haven't used it for any of like our web interfaces because they're, they're a little complex. But I think like we probably could at some point. But our admin tools, like I'm not like a, you know, I was telling you my background about like being infrastructure reliability. I am not a front end engineer by any world, but I've been able to like really build like our admin interfaces really easily with V0 just like very simple prompts and I can get going and be dangerous enough to build something to be able to help us do better customer service and understand sort of where our users are based on our data. And that was actually going through that process was pretty shocking what I was able to do in a very quick amount of time. So pretty excited about that continued evolution there. And some of the stuff that I've seen demos on where it's using 3js to do like you know, spinning world things like that, it's just, it's kind of mind blowing, right? It's, it's, it's really interesting to see what the, the power is there and I'm kind of, kind of curious to see how that continues to grow.

Shawn Falconer (37:26)

And as a, you know, startup founder where resources is always, you know, limited using some of these tools, are you feeling that essentially that you're going to be able to go further with sort of, you know, less people because they're presumably operating a little bit more efficiently?

Joey Parsons (37:41)

Oh, a hundred percent. I think that there is a huge sort of like, I don't know if it's like step level or like exponential, but like it's a. There's quite a big lift on what we're able to do. I was like, I'll give you an example. So you know, we use like kind of off the shelf sort of like background like scheduling system through, through PG Boss. So like our database is program postgres and instead of like going with like a high level sort of like scheduling system, it's like, let's use PG Boss and kind of go down that path. And we were investigating an issue with pgboss and seeing some jobs being backed up and you know, they have a very particular schema and it was kind of, you know, being able to like write a query to like, to look what we were looking for was going to take a little bit of time. One of one of my engineers came back with a query like really quickly and it had all of these different sort of like SQL functions that I'd never seen before. I forget exactly what they were, but it was like, wait, what, what is that? Like what does that thing do? And we ran it and it worked and it gave us the output we wanted. I asked him, did you write that? Do you know all this stuff? He's like, no, I just like, I think he popped it into like Cloud 35 and it was like, came back with like the right answer really quickly. And this is probably something that would have taken, I don't know, if not like an hour or like multiple hours to kind of like really get right. It was something that we had in like a matter of seconds that gave us the exact answer. So that wasn't like, are anybody's like particular expertise in terms of like how to extract this information and just those little moments like that even beyond just sort of code generation and like the tab completion stuff, that sort of stuff ends up being, I don't know, things that really, really save you a ton of time and give you sort of like the superpowers that I think AI intends and pretty cool to see those specific examples Play out very regularly for us.

Shawn Falconer (39:25)

Yeah, I mean it adds up, right? Especially when you're dealing with maybe technology that you're not necessarily an expert in or you're not working in it day to day. And yes, you could figure it out, but how many hours or days is it going to take to figure out versus being able to leverage some of these tools where you kind of know what it is that you want enough to vet the output, but you might not know all the obscure functions that you've been purged from your memory because it's been a while since you touched that thing.

Joey Parsons (39:53)

It's pretty wild. One way to think about this from a beeps perspective is if you think about, I definitely see the world where you can build a lot leaner of an engineering team to solve like you know, really valuable problems for users. Like you're even seeing it today like some of these like early stage startups that have, you know, a ton of traction, that build amazing products and you look at like LinkedIn to see how many engineers you have, they have and like what it's like you know, this huge company, like what seems like a huge company and it's like you know, 10 engineers, right? That's a pretty common thing that you see. The tricky thing though is like you need a decent, a decent amount of engineers to have like a pretty solid call rotation, right. Like you wouldn't want your engineers to be like on call every other week. So like that it's a limiting factor in what you're able to do there. And I think that you know, a company like Peaks could help solve that where you know, instead of having like these really rough on call rotations where you know, you don't want to have them but every two months, right, like you could tighten the loop a little bit by not making them so difficult. Implement strategies that maybe different than like just like the pure week to week sort of strategy or you know, eliminate like a whole class of issues and maybe a human's not on call for some things but yeah, we're not there yet. But I think that like, like what we were talking about before, there's a lot to be improved upon and, but there's a lot of potential there and I think that it's one of those ways that on call needs to catch up with the rest of how software engineering, like software, the software industry has evolved.

Shawn Falconer (41:14)

So yeah, in terms of the engineering like what has been one of the hardest things to build so far in order to bring this, you know, product.

Joey Parsons (41:21)

To market, the easy Answer there is like, the engineering isn't the hardest part. It's like the building the right thing. Right. That's the easiest answer. But I think that, you know, we have unique challenges in that. Again, we're on call for your own call. So we have to be incredibly resilient and have to build that like, brand of trust, and that can be eliminated in an instant. Right. So having all those sort of like, best practices in terms of resiliency and understanding, sort of like our own monitoring of our own system and how we handle those failures, I think it's like has. Has easily been the hardest part. There's not like a specific thing, but it's, it's more so just making sure that like, we're redundant across providers, redundant across the systems that we use and thinking about that way from, from the start is, Is one of the challenges about building a system like this. Right. There's, you know, it's easy, it's easy to like, launch an MVP of a product that doesn't have those sorts of requirements that if you're trying to go after this market in the space where that really matters, it's time consuming, it's challenging, but it's a very important thing to do.

Shawn Falconer (42:23)

So.

Joey Parsons (42:23)

Yeah, Yeah.

Shawn Falconer (42:24)

I mean, I don't think you can underestimate the engineering effort that goes into building like a really reliable tool. And you can't be in the space of on call and reliability where the product is not reliable itself. Right?

Joey Parsons (42:38)

Yeah, exactly. It just won't work. Right. It's like it's one of those things like, I don't know, there's like the. Everybody thinks it's easier than it actually is. Right. Even myself. Right. Like, every time I dreamt about like building a product comparable to like a, like a pager duty, I used to always think like, ah, like, you know, that's something I can build like in a couple weeks. It's, I mean, it's a lot harder. It's a lot harder than that, especially to build that resiliency. Even just like working at Airbnb for a long time, everybody was like, oh, Airbnb is like the simplest product that, you know, what do all those engineers do? It's so much more complex than what you see on the front end. And so much goes into building a product like that. And you take the consumer part out of it and you're building this enterprise product that people that are relying on. It's.

Shawn Falconer (43:21)

Yeah, look at Twitter. Twitter is like the simplest product in the world. Like the first version of that was probably built in like a matter of days or something like that. But the, you know, if anybody remembers the fail whale era of Twitter, like, they were falling over because they basically couldn't meet the scale in reliability challenges. And you know, luckily they had a talented engineering team enough to like, navigate their way out of that and build this, you know, resilient system. But like, the product itself is simple. It's. It's the backend infrastructure to meet the scale needs. That's really, really hard. Especially back then when you couldn't just go and stand up a super elastic system on the public cloud.

Joey Parsons (43:59)

Yeah, yeah, I remember like, you know, 10 years ago when, when people would talk about how simple Twitter was, you kind of ask them like, okay, like, how do you handle the notifications though? When, you know, I guess back then it was like Justin Bieber, right? Like, if Justin Bieber tweeted, like, how would you send all the notifications to all the people that, like the tens of millions of people that followed him? Right? Like, and, you know, you could really see somebody's engineering chops by how they would think through that problem because that's. That. That was a, you know, a serious thing to think about back then, so.

Shawn Falconer (44:27)

Yeah, absolutely. Well, Joey, thank you so much for being here. This was really great.

Joey Parsons (44:32)

I appreciate it. Yeah, it's, you know, on call is such a, like a personal thing to me that I really want to get right because again, like, it's. It's a whole different set of developers that are taking on the on call challenges for these companies. And I would love for them to not have sort of like the experience that I had and like, the pain that I went through. And I'll share, like, one last story that kind of exemplifies this the most. And it's about 10 years ago now, like October 2024, my wife and my then sort of like girlfriend and I were kind of in San Francisco. We were at a bar and like Paddock Heights having a few drinks and decided to walk back to like our, our place in Nop Hill after, you know, having a fun little night. And you know, we're in Alta Plaza in San Francisco, like, overlooking sort of like the Golden Gate Bridge. Just kind of admiring the view. And all of a sudden like, my phone bus is in my pocket and instead of like, you know, like, oh, crap, I was working at a flipboard at the time, I was like, oh, flipboard. Hbase. We're having, we're having some issues here. And I could see sort of like the sadness sort of like wash. Wash over her face because, you know, to that point, we'd been dating for a few years and you know, we'd had family in town and I had to like, disappear to go solve issues. We'd been on vacation where I had to like, run back to the hotel room in like a panic. I remember one time we were in LA in Manhattan beach, and we were at a restaurant and I literally had to leave her at the restaurant and go sit in the car to help revive a startup that doesn't even exist anymore, right. And deal with these sorts of issues. So I just kind of see like the. The wave of like, sadness kind of like wash over her face. Instead of like, reaching into my backpack to pull out my laptop, I pull out an engagement rate and propose to her. And it's a great origin story for peeps, but if you really think about it, it's pretty sad, right? Like, it's. I involved On Call and like, one of my life's, like, biggest moments and used the. Used her sadness about all the times that we've been impacted as a way to kind of like, shock her with a proposal. And, you know, it kind of hits home with, like, how much this has been a big part of my life and how important it is for me to. To really make sure that we, that we fix this and do this in the right way and make sure that, you know, 10 years from now I don't have engineers telling me that they replicated that story and had to had relationships, like, ruined because of. Because of On Call. So if I can just make this one incrementally a little bit better or inspire somebody else to kind of like, join us and help us and help us achieve this sort of like, mission of making On Call better for this, like, next wave of like, modern software developers that, you know, I'll be really happy. So.

Shawn Falconer (47:21)

Absolutely. That's awesome. And that's an awesome story. Great way to end the recording today. Thanks for being here.

Joey Parsons (47:27)

Thanks, Sean. Appreciate it.