Ben: Hello, and welcome to PodRocket. Today I'm here with Ravi Parikh, who's the founder of Airplane and he previously was a co-founder of Heap Analytics. How are you Ravi? Ravi Parikh: I'm doing really well. Thank you so much for having me on Ben: Yeah. Really excited to have you as a fellow founder in the product analytics space. We're big fans of Heap here at LogRocket and we are also a Heap user as well and so really excited to have you on and hear about your latest company. So could you give us a overview of what is Airplane? Ravi Parikh: Yeah, for sure. So, Airplane is, we're a pretty new startup. We're just 11 people. We got started about a year and a half ago, and really we built the company to solve one of the biggest problems that I used to run into during my time at Heap. So at a high level what Airplane is, it's a developer platform for quickly building internal tools and automating internal workflows and processes and things like that. Ravi Parikh: So what it really lets you do is if you're an engineer and you find yourself constantly running the same SQL query over and over again, or the same script or on-call runbook or something like that, the idea behind an Airplane is we want to make it really easy to take that one off script or SQL query or whatever eng only operation that you're kind of bottle necked on and turn that into a robust reusable internal app that anybody in your company can use. We do that by basically automatically providing UIs, notifications, permissions, approval flows, audit logs, all the stuff that it takes to turn up piece of backend functionality into a reusable internal app. So, that's the high level idea. I'm happy to dive into detail if you're curious. Ben: Yeah, definitely. So I guess I could give you an example. Here at LogRocket, one of the things that I think relevant here is we often have scripts that modify or edit data in Stripe related to billing, like need to refund this customer payment or something like that. The way we do that right now is we have Slack commands, that our engineering team builds these Slack commands that folks on our support team can run when they're dealing with customer issues. So what would it look like if we want to take one of those Slack command or one of those scripts and brought it in Airplane? Ravi Parikh: Yeah. So, what you're describing is a very common use case for our product and something that we used to do at Heap as well. We had Slack commands for billing type things, we had Slack commands for various types of data deletion type things, GDPR operations, all kinds of stuff. And really what would happen is let's say of that script that hits a Stripe API and issues a refund or whatever it is, what you would do is you deploy it to our system. We integrate with your CICD so that you, as a developer, don't actually have to do much marginal work on top of just writing that script in the first place. You add a short YAML that kind of describes how that operation is supposed to run, quick five line thing that tells Airplane how this thing is supposed to work. Ravi Parikh: Then you'd sort of deploy it to our system and then what we'll basically do is we'll auto generate a web app that's basically like a form that represents that script, takes in a certain set of parameters. You can specify things like input validation rules, you can specify permissions, you can specify approval logic. If it's a sensitive operation that you want to have a second person check off, if where it actually runs, you can do that sort of thing. If it's a long running operation, we'll have things like notifications and things like that embedded into it already. So basically it's all that stuff is kind of provided for you out of the box with very minimal one to two minutes of configuration. So it provides you a higher level of safety and granularity than your Slack commands probably do by default. It integrates your identity, private or provide all that kind of stuff. Also if you love Slack commands, we integrate directly with Slack. So we actually trigger any Airplane task directly from Slack. Ben: Got it. So couple of questions there. I'm curious, first what I deploy code to Airplane, what kind of environment is it running in? Ravi Parikh: Yeah, so you have some flexibility over that. By default, we have a multi tenant set up and so what we'll do is let's say, I'll tell you a quick example. Let's say you have a Python script that's going to hit the Stripe API and do some billing operation or something like that. When you run Airplane Deploy, we're going to look for the requirements.txt file and your repository. We're going to basically make sure that we're including every relevant package that's required to sort of execute that code. Ravi Parikh: We'll archive up that script plus anything around it that's required to run that script and then bundle that all up, upload it to our servers by default. You can also self host, but either way, when someone hits execute into Airplane UI, basically, that agent is kind of long polling and waiting for that execution command to happen. We pass whoever parameters someone has entered into Airplane and then we'll basically just run that script in a Docker container. So you don't have to really worry about the infrastructure management, even if you're self hosting it, the self hosted agent is pretty easy to set up. Ben: Got it. So it's kind of like Heroku in that sense where I'm not worrying about things as a low level, as a Dockerfile, but more just requirements.txt, what Python libraries do I need for this script to run? Ravi Parikh: Right, and we have a builder for Python, for Node, for Shell, but you can also... We give you that flexibility if you want to get down to the level of granularity of worrying about that Dockerfile, you can do that too. Ben: What about things like environment variables in terms of API keys because I imagine often you're going to be running scripts against a production database or production Stripe. So how do you handle storing sensitive tokens or API keys? Ravi Parikh: Yeah, so basically what we do right now is there's just a key value store in our product. So you could go in and enter some Stripe API key or some database credentials or something like that. If it's secret, you can market a secret in our UI, which means it just won't show up to the end user. It is stored on our servers, but everything is encrypted in transit, encrypted at rest. Then when you're basically building a script in Airplane, you can configure which environment variables you want to have past in, that sort of thing. We will sort of in the future have direct integrations with things like Vault or Doppler and stuff like that to make it little bit more secure, but that's kind of how it works right now. Ben: Got it. I'm curious to learn a bit more about the types of UIs you can build to interact with a script that you launch. So you mentioned that some UIs automatically generated, is that based on code you're right or is that based on configuration [inaudible 00:06:32] or what is the process for defining the form or the UI that is an input to the script? Ravi Parikh: It's kind of the latter. So basically, everything in Airplane is just a function that takes in a certain set of parameters. You tell us what those parameters are. If you say this is a refund user script for Stripe, you might say, this is the email address of the user that we want to refund, and this is their transaction ID or something like that and these are both strings and here is maybe some input like [inaudible 00:06:59] that they have to match in order for this to be considered valid. We have a lot of flexibility in terms of input types. You can do files, date, pickers, all that kind of stuff, but everything really manifests as kind of a web form. We try to keep it really simple. Airplane is not like a UI builder tool. We don't want you to drag and drop a bunch of UI elements around the screen and have a lot of control that way. The idea is for you to really just concentrate on the logic of the operation and we'll sort of auto generate the rest. Ben: What about output, if you're script output, say output a graph or a chart or things like that, or mostly text based now. Ravi Parikh: It's pretty simple right now. So basically we have kind of two output streams that happen when you are on a script. So there's just the typical standard output that's more there for debugging purposes, if you're a developer, but then there's also kind of what we call named outputs, where you can say like, "Hey, when we were on this refund script, we don't want to show something to the user that says that this is a successful refund or something like that." So you can just pass a JSON object in, we'll kind of display it as a table or a static text or something like that. We don't really have graphing capabilities, things like that. We are going to add richer outputs over time, but it's pretty simple right now. Ben: Is there a construct for a script that requires a few back and forth interactions? For example, show me a list of recent failed payments in Stripe and press a button to retry each one and so kind of the script is interacting with the user. Ravi Parikh: Right. Yeah. So, basically, what I've been describing so far is kind of the base level concept of Airplane, which we call a task, which is kind of a single function, essentially. It does takes in a set of inputs and then has a set of outputs. The sort of construct you can build on top of that is something that we released a couple months ago, which is called runbooks, and a runbook basically lets you chain multiple tasks together. So you have quite a bit of flexibility in how data is passed from one step to another. You can do things like have it pause and ask for additional input. So exactly what you're describing, run some sort of query that does a read essentially and shows a list of transactions, let the user choose one of them, pass that into the refund step or something like that, is a very canonical use case for runbooks. Ben: Got it. And that kind of reminds me of Zapier or Zapier. I never know how to pronounce it. So I'm curious, is that something you took inspiration from and kind of compare and contrast maybe the ways Zapier works, things you can do in Zapier versus how you're building Airplane. Ravi Parikh: Definitely. Yeah. So sometimes I describe Airplane as Zapier or Zapier, build your own Zapier, almost. Zapier is stitching the other third party APIs. It's saying, take this data out of Salesforce and put it into Google sheets or something like that. Our thing is really in some sense stitching other first party API. Obviously, Stripe is a third party operation, but it's sort of letting you take those kinds of things and stitch them with your production data and stuff like that as well. So if you wanted to do something like a data deletion, runbook where what you're doing is first it's going to hit a production database and delete some data, then it's going to hit the Intercom API and unsubscribe them from future email emails, and then it's going to send an email to the user saying your data's been deleted. Each of those steps, some of them hit third parties, some of them at first parties. You as a developer, want to have some control over how the code is executing each of those steps. That's kind of the intent of what we're doing. Ben: Got it. Yeah. I think Zapier, they do have zaps that let you run some JavaScript or some Python, but it seems that they haven't really invested in the whole developer experience around that in terms of... Maybe I'm wrong, but last I checked, I don't think you can kind of do CICD integration or have code being pulled out from GitHub, or I don't know what their testing story is. Ravi Parikh: Yeah, I think the main difference there is Zapier, and there's other tools out there that let you integrate like Python or JavaScript into some sort of workflow type thing. It's usually executing kind of in their environment. So, the idea of basically integrating into your code base and looking at requirements.txt file and bundling up a bunch of other stuff, is not really a thing you can do there. It's going to be kind of hard from my understanding at least to write code in Zapier that's going to hit your production database, for example. You can always have it hit like a rest end point that you've built and exposed to the public internet through Zapier but if something is not a arrest end point, essentially, if something's just a script that you want to run one off as a step, you're not going to really be able to do that. I think super effectively from my understanding. I don't want to mischaracterize what there to do. Ben: Yeah. I think that's been our understanding as well, though I have haven't looked at that functionality in maybe a year or two, but in the past, that was kind of the limitation I've seen as well. I'm curious, you mentioned before the concept of approval logic, it sounds like there's a permission role based access control type system that you can define on a per script basis. So curious to understand a bit more about that. Ravi Parikh: Yeah. So this is a big part of why people use Airplane. So basically on any task that you build an Airplane, you can basically... Well, even before you get to the task part, you can feel integrate with your identity provider, we'll import groups and things like that. So let's say you have, to take a simple example, you have an engineering group and you have a operations group and you need to give the operations group access to some delete user script. Let's say that delete user script is irreversible. It's fairly sensitive, not something you want someone to just hit a button and poof, the data's gone. So what you can do is you can basically set that the operations group to have approver access on that script. So when they go to delete a user, they won't actually be able to click execute. Ravi Parikh: What they'll do is click a button that says request, they'll have to provide a reason. They'll have to pick a reviewer from a list of people who are in a executor permission group or higher. Then one of those people will get a Slack notification where it says, "Hey, someone's trying to run this. They did Allegion task with user X, Y, Z. Would you like to approve it or deny it?" They just hit a button in Slack and then boom, sort of either happens or doesn't. The advantage of this is with really just a couple clicks, 30 seconds of work, you can impose this approval that'll be fairly complicated to build if you build it in house or in a third party service or something like that. Ravi Parikh: The nice thing about this is you get to sort of balance access and safety. Often what I've seen in a lot of companies, or what I saw at Heap, my previous company, was you have a lot of these really sensitive operations and the reason that people don't have self serve access to them on their teams, is really just this idea that like, "Oh, they might not understand the consequences of running this thing," or, "We don't like to give government right access to these internal systems." Approval falls, let you basically have your cake and eat it too. Give everybody access, but in a way that's very constrained. Ben: Yeah. Makes sense. You mentioned before as well, self hosting. Ravi Parikh: Yeah. Ben: I'm curious, what's the process to self-host a Airplane instance and what reasons you generally see customers choosing to offer self hosted versus the SaaS version? Ravi Parikh: Yeah. So it's not a fully self hosted product, it's hybrid. So what, what I mean by that is the control plane that where the sort of execution happens lives in our cloud, no matter what, but you can self-host where the script actually gets executed. So you can basically say when, the sort of Airplane UI will always be kind of on our servers, but when someone clicks execute, instead, you can have an agent that lives behind your VPC, long polling waiting for that execution to happen, run locally. We won't actually see that execution. Ravi Parikh: Then whatever outputs and logs get emitted from that script will get sent back over the wire to us. They are encrypted in transit and encrypt [inaudible 00:14:04] rest. We may bring logs [OnPrem 00:14:07] as well in the future. We haven't really decided that, but we probably won't do a fully OnPrem solution, but we think this balance is kind of our ability to sort of provide a managed SaaS solution that you don't really think about while also giving you the sort of control to say, like, "Hey, all the sensitive stuff is going to happen behind our VPC and all that kind of stuff." Ben: Got it. And I imagine from a cloud architecture perspective, if you have commands being run against a production database or something like that, it makes it easier to avoid breaking your existing security model. Ravi Parikh: Right? Yeah. And I would say almost all of our customers above a 20, 30 person company are self hosting or using this self hosted agent, rather. Ben: So curious to hear a bit about the future. What is the next year or so look like in terms of features and parts of the platform that you're excited. Ravi Parikh: Yeah. So there's quite a bit that we're investing into. So I'd say first and foremost, we see Airplane as a developer tool. It's not a no code solution or something like that. It's really intended for developers because we see one of the strengths of Airplane is the ability to kind integrate directly with their code base, right against production data, all that kind of stuff. As a result, a lot of what we're doing is making that developer experience better and better and better. So I kind of described how Airplane works today. You can write a Python script, you can put a YAML file next to it. That'll describe what the task is. You can deploy it. It's okay to be totally Frank, but we're going to take it from something that's good to something that's a big strength of a platform. Ravi Parikh: So we want to make the deploy speed really, really fast. So that iteration between deploying something to Airplane, trying it out, making sure it works, going back and editing it, is really, really smooth. It's kin of what you're used to from best in class developer experiences, hero, sell things like that. Other things that we want to do, first class support for things like environments and stuff like that. You right now, and someone's Airplane account. They have like task name, staging task, name, prod, all that kind of stuff. So we want to make that sort of thing a lot easier. We also want to have a lot more sort we're not trying to be Zapier where we have like 500 integrations and things like that. That being said, if we can have it so that you avoid having to write some boiler plate code, we do want to do that. Ravi Parikh: So we do have, for example, direct integrations with databases or rest and things like that. So, you can write a Python script to hit a rest endpoint, but you can also just use a rest builder to do that more directly. And so we'll have more of those kinds of integrations with more data stores directly integrated with more. Patterns like, graph well and things like that, that we directly integrate with. And maybe a couple third party things like you mentioned Stripe, a lot of people do billing operations and stuff like that. So Stripe charge me. Maybe there's a couple things like that, that we'll do. We're probably not going to have a long tail of 500 integrations and things like that. Other big things we're working on are just better richness in terms of the UI patterns that you're able to use in Airplanes. Ravi Parikh: So I mentioned everything in Airplane manifest as a web form, and then we have really simple outputs with just static text or tables and things like that. We do want to have better support for things like graphs and stuff. Also, a lot of what people use Airplane for are scheduled operations. They'll be like, "Hey, run this query every day and the take the output of this SQL query they're running every day and spit it out in Slack on a daily basis. Maybe some daily report or something like that. Just better being able to give people some flexibility around how that's displayed and stuff like that. It's minor but I think it does make a big deal to what people can do with the tool. And eventually, Airplane, I think is really good for these task based workflows, delete a user issue or refund or something like that. Ravi Parikh: There's a lot of work that people do on operations and support that are more exploratory. So it's like maybe a user writes a ticket and they're probably not saying refund me right away. They're probably saying something like, "Hey, something's weird about my billing." So probably what you have to do is two or three or four read queries first before you actually then realize what you need to do is issue a refund or something like that. So those like exploratory read type interactions, I think often are hard to model an Airplane, because everything in Airplane is a very explicit, rigid kind of function. So we have some ideas for how to basically better execute those kinds of workflows in Airplane as well. But through all of this, we really see Airplane as both a developer tool and a tool that's not intended to make you think very hard about how things should look or feel or things like that. Ravi Parikh: We're not trying to be an app builder or a silo or something like that in your org. We're trying to be something very simple. So we're not going to build like a full fledged massive experience where you can paint on a blank canvas, whatever you want. We want to keep it very simple. The strength of Airplanes so far has been that the cognitive overhead and the time that it takes to create new stuff in an Airplane is really, really low. We want to preserve that sort of mode for the future as we have our functionality. Ben: Got it. Yeah. No, all exciting and I think you've mostly answered this question already, but curious where you see yourselves in comparison to something like a Retool. I think the answer lies kind of in that they have a lot of around building UIs, but I'm curious to hear from you kind of... Ravi Parikh: Yeah. I think Retool's a great tool. As you said, a lot of its strength is in allowing you to build UIs and things like that. I think there's pros and cons to their approach. I think the pros are that you have a lot of flexibility and a lot of power. I think the cons are that for a lot of these internal workflows, you don't really need that flexibility or power. It doesn't really matter where on the page a thing exactly displays, if what you're really just trying to do is build a simple workflow. I think Retool is very sort of akin to something like a web flow or a dream Weaver or something like that. But the difference is things like web flow and stuff like that are allowing you to build experiences for the sort of general public. Ravi Parikh: Whereas like with Retool or Airplane, you're building experiences for a small set of users who are very highly engaged with the thing you're building, because your teammates at your company who need to run various things. So getting the exact UIUX right, is actually a lot less important than making it really easy to develop because making it easy to develop means you're going to do more things and you're going to the barrier to taking an end only operation and turning into something that people can use is far lower. Ravi Parikh: So I think we air philosophical more on the side of just having strong defaults and automating away as many decisions as possible. So that you're really only concentrating on the differentiated bespoke piece of logic that's specific to the operation. So that's kind of philosophically the difference. I would say also mechanically we've kind of focused on these more right workflow type operations rather than these more re DUI heavy type operations but even as we kind of converge onto some more of that stuff, I think we're going to have a different flavor of how we approach the problem. Ben: Pivoting a bit. You previously, as I mentioned before, previously founded Heap analytics, which is a successful company in the product analytics space. I'm curious when you set out to start company number two, what did you do differently or how did your learnings from that first entrepreneurial experience inform the early days of figuring out what even you were going to build with Airplane? Ravi Parikh: Yeah. I mean, there's a lot we did the same, to be honest, because Heap was relatively successful, but in terms of things that we did differently, I would say at, and some of this is just sort of a luxury, the position we're in an Airplane too, but at Heap I think we pushed on monetization a lot faster and a lot earlier. And so initially Heap had a self-serve product with a free tier and all that kind of stuff. But we quickly found that there was like pretty high willingness to pay with mid-market and enterprise customers. So we restructured our pricing around that really quickly. And I think that it was generally a good move and I think it's paid off well for the company, but you sort of lose that kind of organic bottoms up groundswell of adoption when you do that too early in a company's life cycle. Ravi Parikh: It's not even just like, oh, we'll do it later. It's more that there's like- there are companies out there like Atlassian and stuff like that, that have found a way to sort of have pricing and packaging and a go-to-market motion that appeals across the board, right. They don't shut off their SMB to sort of satisfy their enterprise they're enterprise or whatever. Every company's a little bit different. But I think with Airplane, we really see this as a tool that we want individual developers to adopt. We see this as a tool that should be really, really lightweight and fast to get started with. And as a result is going to have a high amount of value to a small startup. So I think we want to be a lot more intentional about structuring or pricing or packaging or go- to-market to allow small companies to use this tool forever and not squeeze every dollar out of every market segment. Ravi Parikh: So I think that's something we've been more intentional about. I think we have the luxury of being really well funded, which he didn't always have in those early days so that we can be a little bit push off revenue generation for a little bit longer. So I think that's one big difference. I would say another big difference is this is more just the type of product that I wanted to build, but Heap was going into a fairly well established category already. In some sense, analytics is the oldest or one of the oldest SaaS categories out there. Adobe Omniture, Google Analytics, Google Analytics actually predates Google. It's a company called Urchin that they acquired. So it's a really old category of SaaS software. So we were entering into a space where we had a very clear innovation, a very clear value proposition, but we weren't doing a lot of market education in terms of like, "Hey, here's new ways to do things." Ravi Parikh: So I think with Airplane, it's actually very different. You asked about how we compare to Retool. That's one of 20 things we get compared to, which are not at all in the same category. People will compare us to Rundeck or Airflow or CSCD systems or all kinds of things out there that make it on one hand a little bit annoying sometimes to have to have so many different types of conversations, but also make it really, really exciting that we can build something that is a little bit amorphous. It's a lot more creative, I think in terms of what we decide to do, what we decide not to do, what we consider to be in scope and not. I think that uncertainty and that ambiguity and that creativity and that space is really interesting for me. Ben: You mentioned before that one of the initial inspirations was that at Heap, you had this problem of, as I described before, you had all these internal scripts, maybe made them as Slack commands, but that was part of the input to what gave you the idea for Airplane? How did you get eviction that that was a widespread problem or something that there was enough potential customers out there to build a business around? Ravi Parikh: Yeah, for sure. So I started Airplane with a friend of mine named Josh, he was previously CTO of a company called Benchling and he was employee number one at Benchling, helped them scale to about 300 people and they're still doing really well. So when him and I were kind of deciding to work together and talking about kind of various pain points we experienced, he had had the same set of things happening at Benchling as we had at Heap. So that was two data points at the very least. Towards the end of 2020, when we were still kind of in an exploratory mode, we spent a lot of time just talking to friends of ours at other companies, developers at other companies, and just getting a sense of like, "Hey, how do you handle internal tooling? Is this a problem that resonates with you?" Ravi Parikh: We saw that at lots and lots and lots of companies that they were experiencing very similar things. Then we also saw that there was a couple larger companies, companies like Stripe and Airbnb and Coinbase and stuff like that, where they had built systems that looked a little bit like how we were thinking about Airplane. It was still really early at that point, but we had some mocks and put together a deck and we're like, "Hey, would you use something like this?" We're like, "Well, we do use something like this, we built it ourselves." So that gave us some confidence that like, hey, if the companies with tons of resources have decided this is a pattern that makes sense and people are using it really heavily within those companies and the smaller companies are struggling with this problem and there's probably some SaaS solution to be built here that can make a big impact. Ben: I'm curious, how are you thinking about distribution? I know that when I talk to founders that, and especially second time founders, it feels like something that is always front and center. So I'm curious, you mentioned earlier that one of the core things you're optimizing for is for small companies, individual developers to always be able to use this. How are you reaching those folks? Ravi Parikh: Yeah, for sure. So I would say the high hill answer is still to be determined, to some extent. We're super early. But the way we see Airplane right now is we don't have the luxury that Heap had of being an established product category where there's already a ton of high intent search volume for people looking for exactly product analytics or something like that. So, there's not quite as easy of a strategy of just kind of drift off a level of intent that already exists. But the thing that we do see is a lot of people who are trying to solve the problems that Airplane solves using other tools that aren't necessarily adapted for it. So to give an example, a lot of people use Airplane as kind of a lightweight substitute for Chron or Airflow. Ravi Parikh: We don't pretend to be a super sophisticated orchestration engine or something like Airflow, but for a lot of the really simple stuff that people are doing with tools like Airflow, Airplane's just going to be easier to manage, it's going to be easier to use and stuff like that. So I think there's an opportunity there to find the people who are struggling with those things and write content for them, find the communities where they're hanging out all that kind of stuff and say, "Hey, here's maybe a way you can solve maybe 70% of what you're trying to do. The bottom 70% in terms of sophistication of what you're trying to do with Airflow, with something that's going to be managed and a lot simpler to use." Ravi Parikh: There's a lot of stuff like that. There's a lot of people out there trying to use CSCD systems. One thing that Josh, co-founder, actually built at his previous company was he built a system using Buildkite to basically run scripts internally and it works. IT gets a job done for that, but it's fairly heavyweight. It's something that's really only engineers can still use. It doesn't fully solve that problem. So that's another situation where people are exhibiting a certain pattern that we can kind of find those people and say like, 'Hey, here's maybe a better way to do things." So that's kind of how we're thinking about it, conceptually. So I think there's a strategy there with writing content and finding those people that'll hopefully pay off. Ben: Well, Ravi, thanks so much for joining us today. We are going to put a link to Airplane's website, which is airplane.dev in the episode description for anyone who's interested. Any other resources for folks who are interested in learning about the platform besides the website that you'd recommend? Ravi Parikh: Not really. I think the website's a good place to start. We have a demo video that's three minutes long that does a good job of kind of showing how it works mechanically. Then we have pretty thorough documentation and stuff like that that you can check in as well. Ben: Are you growing the team now? Ravi Parikh: Yeah, so we're 11 total and we are hiring in number of positions. So looking for strong engineers, looking for designers, looking for deployed engineers as well. People who can basically have strong engineering skills, but also want to be customer facing. Even if you don't fit into any of those descriptions, always happy to chat. There's people who we chatted with six months ago and now we're hiring for that role and then we reach back out to them today. So always feel free to reach out. You can just send me an email at ravi@airplane.dev if you're interested. Ben: Remote or certain locations? Ravi Parikh: Kind of both. So we have people all over. We also happen to have a small hub in New York where we have... I'm based here, but my co-founder is based in San Francisco. We have folks in Canada, we have folks in Singapore, kind of all over the world. Ben: Awesome. Well, it's been awesome learning about Airplane and I'm excited. I think we're going to check it out here at LogRocket. So thanks again. Ravi Parikh: Awesome. Thanks for having me on. Brian: Thanks for listening to PodRocket. Find us at PodRocketPod on Twitter, or you could always email me, even though that's not a popular option. It's brian@logrocket.