Ravi Parikh, Founder and CEO of Airplane
Ravi Parikh, Beyang Liu
Beyang talks with Ravi Parikh, founder and CEO of Airplane. Airplane is a developer tool for turning one-off scripts into internal mini-apps that can be used by technical and non-technical users across the company.
Ravi shares his journey as a programmer, how he got into computers at a young age, took a brief detour to become a professional musician, and then started his first software company, Heap Analytics, with his friend Matin Movassate. Beyang and Ravi discuss what took Heap from idea to billion dollar company. Ravi discusses founder-led support and the ways he and Matin managed Heap’s growth from an analytics tool geared towards developers to a full-fledged analytics platform with users across product, sales, and marketing.
Ravi explains the seed concepts that led to the founding of Airplane and then demos how to use Airplane to turn a one-off support script into an internal mini-app that you can reuse again and again. The conversation concludes with a discussion of what’s next for Ravi and Airplane.
Ravi talks about learning programming as a kid, taking a detour to be a professional DJ, and getting back into programming (00:34-7:31)
Ravi touches on the projects he and Matin worked on prior to Heap, as well as Matin’s frustrations with analytics while working at Facebook which ultimately led Ravi and Matin to found Heap (7:31-10:20)
Ravi explains how Heap reached product-market fit (10:20-19:01)
Ravi discusses how they scaled Heap from primarily a developer-focused analytics tool into something more low-code that managers, marketers, and analysts could easily use (19:01-23:30)
Ravi talks about how his experiences working in support at Heap seeded the idea for creating Airplane as a way to alleviate analytic pain points by automating internal scripts (23:31-28:35)
Ravi demos how to use Airplane to turn a one-off support script into an internal mini-app that you can reuse again and again (28:35-43:10)
Ravi talks about Airplane as not just a developer tool but as a tool to be used in conjunction with low-code or no-code tools (43:10-49:18)
Ravi and Beyang discuss Airplane’s target market and its goal of making Airplane usable by every software team (49:18-51:12)
Beyang and Ravi discuss what’s next for Airplane including: optimizing the local dev experience, using Airplane as a replacement for simple data pipelines, and possible editor plugins (51:12-59:59)
Links Referenced:
- Email: [email protected]
- Airplane: https://www.airplane.dev/
Ravi: That difference was actually pretty huge for people. Because the nature of these things, it’s stuff they don’t want to be worrying about, right?
Like, as a developer, you’re like, “I don’t want to do this thing over and over again. I want it off my plate as soon as possible.” And Airplane sort of fulfills that for you. It’s like, “Hey, we’ll get out of your way. And we’ll let you automate this thing. You send the link to your other teammate who needs to run this thing and then you’re done with it.”
Beyang: All right, welcome back everyone to another installment of the Sourcegraph Podcast. Today I’m here with Ravi Parikh, the founder and CEO of Airplane, a new SaaS developer tool that helps productionize all those one-off scripts you end up writing to manage and maintain your modern cloud services. Ravi previously co-founded a company called Heap Analytics, a user analytics tool that helps product and marketing teams understand their users and customers. Ravi, welcome to the show.
Ravi: Thank you so much for having me on.
Beyang: Awesome. So, I’m going to kick things off with, you know, the question I always ask every guest who comes on the show. How did you get into programming?
Ravi: Yeah, of course. So, it’s a while back, I probably got into programming around, like, you know, when I was 10 or 11 years old. This was back in, like, the late-90s. So, we had just gotten, like, the internet at our house, just, like, dial-up modem. It was I think NetZero was the name of the service. And yeah, so basically, I thought this thing was pretty cool and I wanted to make my own websites.
So, you know, I found, like, one of those online free website builder, Geocities-type things and started there with, like, those kind of WYSIWYG UIs and stuff. And I wanted to do more sophisticated things. And by ‘my own website,’ I don’t mean, you know, anything super interesting; I mean, like, a place to share video game cheat codes, or whatever I thought was cool at the time. And so, I think I was using Dreamweaver. I, like, got a copy of Dreamweaver from, like, my dad bought me a copy of Dreamweaver and then I started playing with that to, like, build websites and stuff.
And so yeah, just basically did a lot of, like, WebDev type stuff throughout the next several years, increasingly building more sophisticated things. And then I was really fortunate to go to a high school that offered a couple programming classes, so I learned some, like, basic C++ Java stuff as well, and learned, like, the basics of object-oriented programming and all that kind of stuff. So yeah, really just developed a love for, like, building stuff and seeing the product of what I’ve built. Everything else that I ever learned at that time in my life was like, oh, you learned this cool thing and math class, or history class, or whatever, and it’s just sort of—it feels like it’s just information in your brain. Obviously, it’s sort of building patterns and concepts and stuff that will help you be a good person or whatever, but this was like, “Oh, I learned a cool thing,” and then I can, like, go and, like, hack it together and say, like, “Hey, I made this thing.” That was like, incredibly rewarding, and that feedback loop just sort of grew.
Beyang: That’s awesome. So Dreamweaver, you’re building websites as a kid, and then you studied some amount of programming computer science in high school. I understand that you didn’t go and become a professional software engineer straight away though. There was a bit of a detour in your life.
Ravi: No. I think if you took a kid who had been building websites and writing code since ten, and then took programming class in high school, and then majored in computer science, and—I don’t think you’d get what happened next. But after I graduated college, I was actually a professional musician, like, a DJ slash producer for a couple of years. So really, another hobby of mine, a lifelong hobby of mine has been playing music and then writing music as well. I’ve always written songs. I was in bands in high school and stuff like that.
And so, in college—well, I was in a band in high school and then I went to college, and then I didn’t have a band anymore, so I started making EDM because you can make it by yourself on a laptop alone.
Beyang: Yeah.
Ravi: And then so I got really into making electronic music, I put a lot of my stuff on the internet, and then around, like, 2010, 2011, a lot of my stuff got very popular on SoundCloud and YouTube and then people started paying me to do shows. And then when everyone else was applying for jobs, I was like, “Well, I could keep doing this thing.” So, I kind of kept at it for a couple of years before I went—well, before I made it back into what I was probably meant to be doing anyways. But yeah.
Beyang: Was there anything that you, kind of like, took from the music world that informed the way you approach software and code?
Ravi: Not in a direct sense, but I would say, indirectly, I think the thing I loved—so I’ve been making music my whole life, but, like, when I was in high school, I was in bands with, like, multiple people and you have, like, physical instruments, and then you have to, like, record things, like, on your guitar and vocals and all that kind of stuff, and then you got to spend a lot of time, like, arranging it and putting it together. And it’s like—and then you see a final product of what you’ve built. And that feedback loop is really slow. And then nice thing about—like, I wasn’t even into electronic music.
I got into it because of the ergonomics of how you make electronic music. It can be done all software, all on your own computer, all the digital stuff. And you, like, program in a melody or something like that into a VST, into your thing, and then click the play button, and what comes into your ears is literally identical to what the end-user is going to hear, which is not true of, like, a physical instrument or something like that. And so, the feedback loop is way, way, way far. And also you don’t have to deal with five other people and coordination.
So, that the idea of, like, just, like, fast, fast feedback loops and that reward that, like, instant dopamine rush of, like, making a thing and seeing the thing, and that, like, it’s true of electronic music, it’s true WebDev, and it’s something that I, like, I’m very attracted to. I don’t have the patience for, like, long cycles and planning things out, and thinking through things, and, you know, working in that way. So, I think that’s always been really appealing to me, and that’s why I’ve found myself doing the things I’ve always done. That’s why I’m working on, you know, a SaaS tool now, rather than many other things in the wide world of tech that I could be doing instead.
Beyang: Yeah. Fast iteration times. I think those are, like, really key, and I think a lot of developers out there would find what you just said, just, like, spot on.
Ravi: For sure.
Beyang: Yeah. Okay. So, what was kind of the journey? You’re making music professionally for a while; what brought you back into the software world?
Ravi: Yeah, I mean, so, like, I made music professionally, like, accidentally, to be honest, right? Like, I made music, I put it on the internet, it got popular, and people started paying me to show, so I kept doing it, and I sort of stumbled into it. But the, you know, the nature of it is, like, you’re playing shows, maybe Friday, Saturday night, maybe Thursday night or something like that. Most of—you have a lot of free time, and in that free time, I made music and stuff like that, but I wasn’t a super-disciplined 21-year-old when it comes to that stuff, so I had a lot of downtime. And sometimes in that downtime, I, you know, watched TV or whatever, but other times I just, like, hacked on stuff with my friends.
So, a good friend of mine from college, Matin, right after college, he went to Facebook and worked there for a little bit, but then he left Facebook and was hacking around some startup ideas. And then I kind of worked with him on a few different things that kind of went nowhere. But then, you know, one day he sort of came up with this idea for Heap. And, you know, we started working on that together. I actually didn’t start working on it together with him initially. It was just one of the many projects that he was working on. It was like, “Yeah, that sounds interesting. Whatever.”
But, like, you know, he was persistent and he said, “Hey, I think this is going to be a really special idea,” or something like that. And then he kind of convinced me and I was like, “Yeah, this makes a lot of sense.” So, also kind of stumbled into that to be totally honest. And then we started working on Heap together, we did YC together, raised some funding, and then it became very real, and I was like, I can’t, you know, tour [crosstalk 00:07:15]—
Beyang: [laugh].
Ravi: —anymore. So.
Beyang: It won’t work. The co-founding a company and touring professionally, both—
Ravi: Yeah.
Beyang: —rather time intensive. [laugh].
Ravi: Yeah. A little bit different. So, yeah. And then I was just heads-down on Heap for the next several years.
Beyang: Interesting. So, I think, you know, one of the things folks would be curious about is, like, what were some of the other ideas that you explored? What was that, kind of like, primordial soup, like, of ideas and experimentation? Are they all, kind of like, similar to Heap? Or were they different or—
Ravi: No they were pretty different. I mean, so I wouldn’t even say that, like, what I was doing was exploring startup ideas. Like, what I was doing at the time—this was back in 2012, right—like, I was making music, I was doing my own thing. I was like, it’s fun to hack on side projects. Mateen had left Facebook, he was kind of thinking of it more as, like, startup ideas, but even then, we just wanted to hack on stuff together because we’re friends and wanted to work on stuff together and we had the time to do it.
So, we made, like, really dumb stuff. Like, we have, like, a meme generator. Like, you know, those memes where you have, like, the text at the top of the text on the bottom, we, like, made a thing where he can make those really easily. There’s, like, 100 of them on the internet, but, like, at the time, they all—they weren’t very good, and we were like, “We can make a better one.” So, we made one that was better, supposedly. I don’t know.
And we did, like, a few other things like that, like, really silly, kind of, social app type idea type things. And then I think, like, one of the reasons we built Heap—I mean, Mateen had worked at a real job before at Facebook and he had, like, firsthand struggled with their internal analytics system. And then in a lot of these other things we felt, you know, the first thing you do is you, like, throw Google Analytics on there, or Mixpanel or something like that, and then we always, like, had some pain around, like, oh, you built this thing? We shipped it. “Oh, looks like some people are using it.” “Oh, what are they doing?” “Oh, I don’t know.”
Beyang: Yeah.
Ravi: And so, we constantly had this, kind of like, some minor pain with analytics. And so, Mateen kind of came with this idea, like, the problem that we always had with a lot of these small apps and widgets we made—and that Mateen had a much greater scale at Facebook—was, you know, you ship something, you would track the things you thought were important, and then people would use it, and they’d use it in ways you didn’t expect, and then you’d be, like, “Oh, but I don’t know what’s actually going on there. I wish I had tracked X. I forgot to track them clicking on that button, or I didn’t track that string because I didn’t think it was that important, but that’s actually where they’re going.” So, there’s stuff like that you would think of later, and then the idea for Heap was like, Mateen was like, “Well, why don’t we just track everything people are doing client-side and, you know, vacuum up all that data? And then what do you think of a question later on, you can go back in and retroactively pull out that data point, even if you didn’t think it was interesting at the outset.” So, that’s the idea behind Heap and that’s kind of how Mateen, sort of, came up with that idea.
Beyang: Yeah, yeah. I remember that because, like, you and I go back to college as well and I remember chatting with you in those days. And I think the original way that Heap was pitched to me was, “Hey, like, you’re never going to be able to fully anticipate all the different ways in which users are going to use your product, so why not just track every single user action, we’ll capture, you know, all the CSS tags and DOM events, and then later you can kind of construct your analysis on—”
Ravi: Exactly.
Beyang: “On top of that.” Which is really cool. And talk more about how that idea kind of evolved. So, like, first, it was you and Mateen working on this thing that would allow you to track usage of your own, kind of, pet projects. How did that become a company? At what point did it become kind of, you know, real and, kind of like, a serious thing that you both decided to, kind of like, go all in on?
Ravi: Yeah. So yeah, exactly. It started as something pretty small. Mateen just hacked together this, you know, probably 100-line JavaScript script that you could drop into a website and it would just track every relevant DOM event—every click form submission, tap, page view, whatever—and then just, like, shove that into some database. And then you can just query the database if you wanted to.
And if you, like, forgot to track a certain thing, then you could be, like, “Oh, well show me all instances of clicks on, you know, the div that has the class name, ‘sign-up-button,’” or, you know, whatever. So, that was kind of how it worked. It was just, you know, tracks a bunch of stuff, dumps it into a certain place, and then you can query it, and there was not a whole lot else to it at that point in time. And I remember—like, so actually kind of didn’t work on the initial phases of it. Mateen—like, [unintelligible 00:11:29] projects, Mateen wanted to hack on this and I was like, “Ah, whatever.” Like, that’s kind of how I felt about it.
Because it was more B2B and I had been a DJ for two years, so I didn’t have really strong need for analytics, so it visceral appeal to me. But, so he was kind of hacking on that thing and then I think he just, like, pitched it to a lot of people saying, like, “Hey, here’s this idea. Like, what do you think? Like, you use analytics.” And everyone’s, like, “Oh, yeah, I have that pain point.”
Like, you know, “We always forget to track stuff.” All that kind of thing. So, you hear that enough times you’re like, “Oh, there might be something real here.” So Mateen, kind of like, reapproached me, he was like, “Hey, there’s something actually real here. You may want to work on this.”
I’m like, “Yeah, okay. That sounds reasonable to me.” And, you know, Mateen is a smart guy and I trust him, so, like, a lot of it came down to that as well. So, we started working on it together. And yeah, like, really, like, the way we kind of approached it was, like, hey, we’re solving this fundamental pain point that we had with other analytics tools—Mixpanel, Google Analytics, all that kind of stuff—which was around, like, not tracking all the right things.
But the other things those tools did were quite… fine, right? Like, it’s not, like, Mixpanel funnels are bad funnels or anything like that, right? So, we actually ended up I think, just copying a lot of design patterns from not just Mixpanel, but, like, whatever the best-in-class stuff was the time, Mixpanel, Google Analytics, Kissmetrics, there’s a few other vendors at the time that were doing interesting things—Flurry—and so we said, like, “Okay, like, let’s sort of get to parity on, like, kind of the reporting features and all that kind of stuff and have this, like, core innovation, which was around data collection.” And so, that’s what we ended up doing. And we built, like, a really bare-bones MVP that allows you to track data automatically, you know, specify a CSS selector and an event type, like, a click or form submission or whatever, and then turn that into an event.
And then you can use those events in the typical event-based analytics that you’re used to with funnels and retention graphs and all that kind of stuff. So, we mainly just spent several months, like, hacking that together and building, kind of like, a very early MVP. And we went through Y Combinator and a lot of the early users of Heap were just other Y Combinator companies in our batch. And luckily, they’re also a bunch of tiny startups so data scale was not super large for any of them. So, that was not a thing we had to worry about a ton in the early days, which was nice.
And yeah, and just iterated based on their feedback and things like that. So—and then typical SaaS stuff, did a launch, got customers, listened to their feedback, et cetera, et cetera, et cetera. So yeah.
Beyang: Was there a point at which it, like, really clicked for you? You know, like, whether it was, like, the first customer outside of YC, or you know, a particular user testimonial, or some, like, metric or milestone that you hit when you thought to yourself, like, “Yeah, like, this is really going somewhere, taking off?”
Ravi: Yeah. So… yeah, I would say there is a moment not, like, a specific discrete point in time, but like, there was, like a—there was definitely, like, a period where we kind of, in retrospect, hit a certain level of product-market fit that made it sort of viable business. I wouldn’t say that at the time we understood that that’s what had happened, right? Like, so Heap got started in late-2012. Yeah, we spent most of 2013 just building what I kind of described, like, building the product.
We did a launch in, like, April of 2013. We got a ton of signups for it. Like, the core concept really resonated with people, but there was a lot of ways in which it fell short of the promise. So, one major way was just infrastructure. As I mentioned, all of our early users were small YC companies that didn’t have much data scale, but the moment any, like, real company with any real willingness to pay, tried to use it, it would really—everything would time out and just not work.
So, we spent a lot of time that you’re really just, like, iterating on the infrastructure and making it functional for even, like, modestly-sized companies. So, Dan Robinson, who you know, Beyang, came on board the team at that time as CTO and helped work on a lot of that stuff. So, that was one big bottleneck. The other big bottleneck was—and this was really, like, kind of a mindset shift, too, was we built—Airplane—I mean, not Airplane. We built Heap as a developer tool because we’re developers who are solving our own problem.
But in most companies, the people using analytics aren’t necessarily developers, right? They’re product managers, or marketers, or analysts. And the way Heap worked at the time was, you dropped this JavaScript snippet on your website, it would track every dumb event, every click, whatever, and you would then go into Heap and say, “Hey, when someone clicks on a div with the class name, ‘sign-up-button’ or whatever”—or a button with a class name, ‘sign-up-button’ or whatever—“Call out the signup event.” You have to specify the CSS selector yourself. Most people don’t know—most people who wanted to do use Heap don’t know CSS, so you’re going to have to, like, teach people, “Hey, right-click on the thing that you want to do and click ‘Inspect Element’ and copy-paste that thing over there if you want to analyze it in Heap.” Which is obviously not, like, a super friendly workflow.
And so people—like, we thought of it as this is going to accelerate developers, but what people wanted was, like, low-code, or no-code analytics, really. And so, we weren’t really delivering on that because you still have to understand, like, how CSS and your DOM works. And even if you are a developer, you don’t just have, like, a bunch of CSS class names memorized for, like, what’s in your own DOM. So, you’re still kind of having to, like, do Inspect Element and a bunch of stuff to, kind of like, figure out what you’re trying to define. So, that was like not a great user experience.
And some people figured it out, but the vast majority of people would, like, look at our slick demo video where we kind of gloss over that detail and then get into it and be, like, “Oh, this is actually way more complicated than I thought.” So, we had to improve the infrastructure and we had to build this thing that we call the event visualizer, which was just, like, a WYSIWYG point-and-click way to find events. So, it would pop over onto your website, you could, like, hover over an element, you could see a red box that would say, this is what the element is that you’re trying to find, you click on it, you give it a name, you’d never have to worry about what the CSS selector was. And we’ve put a lot of effort into, like, kind of automagically figuring out what you were trying to click on. Because, as you know, like, the DOM is, like, a nested hierarchy of things, and are you clicking on the outermost div that you’re floating over, or this little button, or just that text within the button?
You know, like, all that kind of stuff is really complicated, so you know, Mateen built, like, a really, really slick interface for sort of defining events and stuff like that. So, we released that, the event visualizer, in February of 2014, and that was the point at which, in retrospect, we—the shipping of that and then we also shipped, like, our improved infrastructure around the same time, some big changes to the infrastructure at that time—so Feb 2014, was the first time where people—people were signing up the whole time because, like, the promise was really good and people were just finding it somehow, but that was the first hour people signed up and, like, a non-trivial percentage of them actually stuck around for the first month, after free trial, and, like, paid and kept paying. We were like, “Oh, that’s kind of new.” Like, they’re not just churning, so that’s cool. And then, like, also, our support ticket volume grew from, like, three to five support interactions a day to, like, 50 in the span of, like, three or four months.
And that was just, like, whoa, people are asking real questions, not just, like, “Hey, can you help me get started,” but, like, “Hey, you know, like, my funnel is showing this data, but it doesn’t really match up with my—” you know, like, that, kind of like, real questions that indicate some level of engagement with the product. And so, it kind of exploded overnight, and in the span of, like, three months, you’re, like, wow, the volume has just, like, really taken off. And so, like that was clearly when we had a sense of, like, product-market fit.
Beyang: Cool. And when you talk about, like, the support ticket volume going up, how did you handle that? Because I imagine the team was still pretty small at that point in time. Was it just, you know, the three of you?
Ravi: Yeah, it was the three of us, and then we had one other engineer on the team. That was, kind of like, the last time I ever wrote code at Heap around that time because I was actually doing all of the support by myself. I mean, we were—like, things that were really specific to something that Mateen or Dan knew well would get escalated to them, but for the most part, I was handling all of it. And so, there was one point, it just got to where I was just answering support tickets literally all day long. And so, that’s what we said, like, “Hey, we should probably, like, maybe hire for somebody to help with this.”
And then so at that point, I basically shifted over onto, like, building out that customer-facing side of the company. So, I hired the first couple of solutions engineers to basically do support and, like, customer enablement and all that kind of stuff. I hired the first few sales reps at that point to handle the inbound kind of people looking to use the product, all that kind of stuff. So, that was kind of the beginnings of that transition over onto building up the go-to-market side.
Beyang: Yeah. I feel like, you know, people talk about, you know, founder-led product and founder-led sales, but we don’t talk enough about founder-led support. I feel like support is one of those critical functions. Because when you’re starting out, it’s literally, like, where the rubber meets the road, right? People are trying to use your product, they’re running into issues and, like, you are literally the only person in the world who can bridge that gap.
Thinking back to early days of Sourcegraph, like, I also spent a good deal of time in the support role. And it seems, like, a maybe, like, not talked enough about thing because it’s so critical to making sure your early adopter users, customers have a good experience.
Ravi: Absolutely, yeah. And I think it’s also—I think something changes when a company sort of creates a dedicated support function and sort of abstracts that away from the founders, the engineers, or whatever. And if you keep those things too separate, which we did, I think, at certain points at Heap, I think the feedback cycle of, like, getting the customer pain points into the ears of the people building products, there’s just a game of telephone that happens there a little bit. And you—whereas when you’re the person who’s both building a product and fixing the issues in the product, like, you have just intuitive sense, even if you never quantify anything at all, of like, what’s wrong, what’s important, what’s not important, what’s repeatable, and you can sort of translate that directly into roadmap in a way that you just inevitably lose, as you grow. Obviously, you gain a lot of other great things as you grow, but you can never really replicate that. And so, I think you should try to not let go of that as much as possible. I think at Heap we let go of that a little bit too soon, in my opinion.
Beyang: Interesting. You’re talking about like that kind of—it’s like the whole user feedback cycle. Like, you know, support—you know, ‘support,’ which is really just you—hears about it, and then relays—in a large company, you’d relay that to the product team and then the product team would incorporate that into the roadmap and trade that off against other priorities. But, like, in the early days, when it’s mostly just the founders and the first couple of employees, it’s like, you are wearing all those hats in some sense, so you can, kind of like, quickly feed user pain and customer asks, just, like, super quickly into adjustments in the product roadmap.
Ravi: Exactly, yeah. And, like, when it’s just the founder doing all that stuff, it’s like, the feedback loop is both fast, and it’s, like, as high fidelity as it’s ever going to get, right? Like, it’s, you know—I feel like when you’re on a certain scale, you’re like, “Oh, we have a support team and a sales team.” And they, like, write all the customer requests into some spreadsheet somewhere, some, like, SaaS product that tracks those things. And then the CEO, 80 customers requested the X, Y, Z feature, but like, that is not, like that’s great that that’s there, but that’s, like, so much thinner than being, like, I directly had the conversation with the customer who wanted the X, Y, Z feature. And, like, actually, the X, Y, Z feature, what it really represents is whatever, right? And I think that, you know, being the same person who hears that and then implements it and scopes that out, that connection is difficult to replicate.
Beyang: Yeah, totally. So, you know, in that experience of running frontline support, were there, kind of, beginnings of what would eventually become Airplane there? Because, you know, as I understand it, Airplane is all about turning these scripts that you might write, you know, as a support engineer, maybe as an engineer supporting the support team to do these, kind of like, ad-hoc or, you know, one-off tasks.
Ravi: Yeah, exactly. I mean, that’s really where the idea for Airplane came from, is, like, the five years I spent running support, sales, professional services, customer success, marketing, all the kind of customer-facing roles in the company. And so, you know, Heap is a fairly complicated cloud product; it’s analytics, and so there’s a lot of ways in which your data can kind of be weird or not the shape you want it to be. And so, for example, you implement a certain identity API wrong and then all of a sudden, you’ve done things, like, grouped 1000 users as one user in a way that’s irreversible or something like that. And then your data is just permanently messed up unless somebody can go and, like, undo that. And there’s no big [unintelligible 00:24:35] undo button in the interface, for obvious reasons.
And so, that kind of stuff would happen all the time. And in these situations, like, our solutions engineering team, or professional services team didn’t necessarily have the tools to, like, solve those issues. Like, these, like, really niche, like, data issues that would take a lot of compute or resources to, kind of, solve it’s not a thing that you just want they have, like, some off-the-shelf button that, like, does whatever. So, what ends up happening is our solutions team, or professional services team, or whoever, would escalate a lot of these things to engineering. So, it’d be, like, these, kind of clean up this data or, you know, somebody wants to fulfill these GDPR requests, or somebody needs even simple admin operations like someone needs and email address changed, or something like that.
Those kinds of things would have to get through, sort of, fulfilled by someone on the eng team. So, someone on eng, we had this library of, like, 70, 80 scripts that we developed over time, so someone from eng would just SSH into a production server and run a script, or run a query, or something like that to solve one of these issues. And then for some of the more common issues, like, these would be constant, like, every few days escalations that people were just getting hit with. And in aggregate, it was happening dozens of times a day.
Beyang: Huge disruption.
Ravi: Yeah. It’s like, it’s very interrupts heavy, there’s a context loss often, like, someone from support will say, “Oh, I need x done.” And someone will do it and they’ll be, like, “Oh, that’s not what I meant.” There’s just a latency issue where, like, “Hey, you found the Jira ticket and then it takes four days to solve because someone, you know, worked on other things.” And so—and it’s just disempowering in general to feel like, hey, I’m customer facing on a candidate solve a lot of their problems myself because I don’t have the tools to do it.
And so, that was kind of the status quo. And the other problem is, like—so we would say, like, “Okay, great. We should just build better tooling for the support team.” And, like, the problem with that is that, like, let’s say you have this script that is very computationally intensive and takes an hour to run, turning that into a tool is, like, pretty non-trivial. Like, you need to put a UI in front of it, you need to have it notify someone when it’s done running, you need to have some sort of mechanism by which it can be rerun if it fails, or something like that.
You need to—you know, what, if it stops in the middle, what are you supposed to do? You need to, like, make sure, oh, this is a, like, very computationally intensive script, it’s not going to tie up resource in a way that’s, like, you know, not what we want. You need to make sure that if it’s sensitive and irreversible, or somewhat irreversible, you need to make sure there’s permissions around so only the right people have access to it. You need to make sure it there’s an audit log around it so that if something bad happens, you know who did it, when they did it. Like, it probably should integrate with your identity provider. When you have a 200 person company, you can’t be adding people manually to this tool every five minutes.
All those things are, like, a big pain to build, right? Like, you maybe wrote that script in a couple hours of work, but, like, integrating with all those other systems to make all that other stuff happen is going to be probably ten more hours of work to really do correctly. And so, that was kind of where the idea from Airplane came. Because all those things I just described, those are kind of boilerplate. They’re the same in every company. The bespoke logic of this script is specific to your company, but the UI, notifications, permissions, audit logs, approval flows, all that kind of stuff is pretty—you know, we can give that to you off the shelf. So, that was the idea behind Airplane.
Beyang: Yeah, that I feel like that pain point, it feels universal. I feel like almost every developer has had an experience where, you know, someone comes to me with an ask, maybe it’s a support engineer, maybe it’s someone on the sales team, maybe it’s someone fielding a customer request like delete this user. Now, I got to go do something. It’s like, not worth building it into the actual product. It’s just, like, a thing that I need to get done. I go hack together a Bash script, I write it once, you know, intending never to think about it ever again. I just need it to do this thing.
And then, you know, a couple days later, same thing pops up and I’m like, “Okay, I guess I’ll revisit the Bash script.” And then later on, someone wants to reuse the script, I send it over and they run it. It doesn’t work and then now I have to, like, field a bunch of questions about this. And okay, so like, that’s the pain point that you’re solving.
Ravi: Exactly.
Beyang: How does Airplane solve it? And maybe we could dive into the product a little bit?
Ravi: Yeah, yeah. I’ll give a high level, and then I’m also happy to show a demo of that, if that’d be interesting.
Beyang: Cool. Yeah, that’d be awesome.
Ravi: Yeah, so basically, the way Airplane works is, let’s say you have that Bash script that you described, what you can do is you, basically—we have a command line utility that you can use to deploy that Bash script to Airplane. And what that means is that we will, you know, wrap that in a Docker container, and then when somebody goes into—and then it can live within your cloud, it can live in our cloud, that’s kind of up to you. We have, kind of, a self-hosted agent which is pretty easy to use that you can deploy behind your own VPC. And then when somebody goes into the Airplane UI, they’ll see that, you know, whatever you named that script, so, you know, call it, ‘Delete User’ or whatever, and it’ll take in whatever parameters you specified and then they can basically just fill out those parameters in a webform, essentially. Hit ‘Execute’ and then it’ll spin up that Docker container, run that script, passing those parameters, and then print out whatever outputs that script generates to the screen.
So really, really simple concept. It’s just sort of like, a wrapper around that script. But the wrapper achieves the effect of not having to worry about, like, the environment in which it’s running. It’s, sort of, serverless; you don’t have to care about it. As the end-user, you don’t have to be technical. You don’t have to, like, know how command lines work to be able to run that script.
You can put some, like, guardrails around it around it, around, like, the input validation rules and all that kind of stuff, so you make sure garbage doesn’t get passed in. Everything that gets thrown in Airplane is audited. If it’s a long-running thing, you can get notified when it’s done running or if it fails. Like, if it’s a really sensitive thing, you can put an approval gate in front of it so that someone can only run it if a second person has said this is okay. So, all that kind stuff is really easy for you to configure as the end-user of Airplane.
The idea is like that Bash script that you described, the first time you write it, you probably just run it one-off. The second time it ever comes up, like, the marginal effort to turn it into an Airplane script should be so low that you never run it a second time, sort of, yourself, right? That should be the idea. And so, we really try to make it so that is literally a one-minute process to turn that script into this shareable, safe widget.
Beyang: Awesome. Can we see that process? Is that—
Ravi: Let’s do it.
Beyang: All right.
Ravi: Yeah, let me—
Beyang: And for folks listening, you know, audio, I will narrate what’s happening on the screen. And you can always go to the site, we’ll drop that in the [show notes 00:30:56], if you want to check out the product directly. [crosstalk 00:30:57].
Ravi: So, this is the Airplane UI. So, this is basically what you see when you log in. And so, this is kind of what an end-user sees. They see a library of, kind of, operations that are available to them. So, all of these represent kind of individual scripts. We call them Tasks, like—
Beyang: So, there’s a giant list. These are all, like, scripts that people have written and, kind of like, productized in Airplane, right now?
Ravi: Right.
Beyang: Okay.
Ravi: Yeah, this is our demo instance, so it’s a little bit messy. There’s a lot of duplication here, but, you know, you can organize things into folders, you can favorite things, all that kind of stuff. But you can basically—it’s just a big list. So, you can search through it, all that kind of stuff, but it’s not super complicated. And so, let’s say you wanted to do something here, you know, like this ‘Issue Stripe Refund’ Task over here.
You just click on it and it’s represented by a webform. And so, as an end-user, you would sort of fill out the webform, you know, type in whatever the details are that you need, and then hit ‘Execute Task’ and then basically, it’ll sort of spin up a Docker container, run that script in, you know, whatever environment that was configured when this was built, and then you’ll see some output over here of what happened. And—
Beyang: Wow.
Ravi: So, you basically have, like, user-readable output over here, which you could just pass in a JSON blob into a print output function that we basically give you and it’ll look like this. And then there’s also just your standar raw logs, which is just, like, stout over here as well. And so, as a developer, you can use [unintelligible 00:32:19] to debug it. If something went wrong over here, you can put whatever you want to stout. But you can also show, like, pretty printed logs to, like, the end-user.
So, that’s kind of what the end-user experience is: very, very simple. You run a script, you get a result, it shows up in this activity log over here where you can see sort of a full history of what everybody has done in here. And so, that’s the end-user experience. Developer experience is pretty simple as well.
So, you hit ‘New,’ and you hit ‘Task.’ And then basically, you get a number of options in terms of how you want this Task to get executed. So, for example, if it was that Bash script that you said earlier, you would pick ‘shell,’ if it’s like Node or Python, you can do that. You can also use, like, SQL and REST to—so if [unintelligible 00:33:01] have write as much code. I’m actually going to demo this using SQL just because it’s sort of the easiest to show in the UI itself. The rest of these require you to use your command line to actually deploy stuff to Airplane, which is actually the prominent way people use it, but it just takes a little bit longer to kind of demo.
Beyang: Okay, so in other words, you have two options, I could write the script on my own machine and then upload it to the Airplane. But you also have, kind of like, an in-the-GUI way of just writing a quick script, which is what you’re showing now?
Ravi: Right. Right. And so, I’m going to show the GUI way of doing it. But, like, we actually prefer that you write these things locally, but [crosstalk 00:33:33]—
Beyang: Sure. But this is for the demo. It’s like—
Ravi: Yeah, yeah.
Beyang: Yeah, yeah, yeah. Okay, got it.
Ravi: Yeah, so I’ll pick SQL over here, I’ll give it a name. So, I’m going to pick something really simple. So, like, ‘Update a user’s email.’ So, this is basically just going to be a Task that updates a user’s email address. So, maybe it takes in whatever their current email is, and that’s maybe a text field, and then it also takes in the new email, and that’s also a text field.
And then over here, I can specify input validation rules, you know, regexes that this should match or things like that if I wanted to. I can also do much more complicated inputs. These are just strings, but I could do file uploads and date-times and stuff like that. So, I’m just going to hit ‘Continue,’ though. So, I pick a database for this to query against.
So, I’ll pick this demo data database and I just specify the query. I’m going to add a couple SQL parameters, just so that we don’t have, like, a, you know, an injection attack, but I’ll do something like this. So basically, what I’m doing here is this params—like, these double curly braces with this params syntax. This is basically—
Beyang: You’re just substituting a value into the script, right?
Ravi: Right. Yeah, so this params is, like, the global object that represents, you know, the two parameters that we specified earlier. And then [unintelligible 00:34:46] query, so it’s something like ‘update users set email :new_email where email :current_email;’
Beyang: You got syntax highlighting and autocomplete. That’s pretty cool.
Ravi: Yeah. I think it’s just some library that we’re using to do all that, but—
Beyang: Okay, cool.
Ravi: Yeah, so you get some simple introspection here on the database and stuff. But, so yeah. So, once we specified our query, I hit ‘Create Task,’ and that’s all I had to do. So, now I’ve taken maybe what I was previously going into the database myself and running and turning it into a thing that anybody can just fill out an email and run. I’m actually—let me pull up an example email so that I can just show it in action.
Beyang: So, what he just did is he typed the SQL into the box and then he templatized it. And so, now it’s like templated by these input fields ‘email’ and ‘new email’ to update the user’s email. And now you have, like, a kind of a button you can click, and then you fill out the form, and then it runs that script for you.
Ravi: Exactly, yeah. So, I’m going to run this Task we just created in 15, 20 seconds of work, and just specify this current email [email protected], and I’m going to just add a ‘+1’ to Billy’s email over here. I’ll hit ‘Execute Task.’
So, it ran it pretty quickly. It’s a simple one-row SQL query, and it says, one row affected. The output here isn’t super expressive; it’s just a simple SQL query. But if I go back to this ‘List all Users’ Task, which is just a SELECT query against that same database, hit ‘Execute,’ and then look up Billy over here, I’ll see that he now has a ‘+1’ after his email address in the database. So, not super surprising.
We ran a simple SQL SELECT query and it updated the database as expected, but the idea here is that, you know, now I never have to go and do this myself again. As a developer. I can just basically have anybody in my company have access to this Task. And there’s very little room for error there. Like, that SQL query is going to—you know, if they were using something like [unintelligible 00:36:37] or one of the SQL editors, there’s, like, infinite degrees of freedom there where you could accidentally [bring up 00:36:42] query without a WHERE clause or something like that.
But over here, you have just, like, a guarantee that this is going to be executed the way you expect. And you also—it’ll live in your activity log. The other thing here is that, if I edit this Task and I go to Advanced over here, I can get a lot more granular about who has access to this. So, if I hit ‘Explicit Permissions,’ I can say, you know, maybe we only want the engineering team, really, to have administrative access, which means only they can kind of run it—or edit it—but you know, I’m going to say, Josh, my co-founder, he’s only going to be a requester, which means Josh can’t actually run this himself. He has to make a request to someone on the engineering team who has admin access, before it will actually run.
So, I hit ‘Update Task’ what Josh would see is he would see a UI that looks something like this. So, same as the previous UI, ask for a current email and a new email, but it also asks you to give a reason and pick a reviewer. And that reviewer would then get a Slack notification which says, “Hey, Josh, is requesting this ‘Update User Email Address’ Task to get run. Do you approve it or reject it?” And so, like, you can really easily add in these kinds of, like, flows that are really important to be able to run sensitive operations at scale in a larger organization.
And so, like, you know, it’d be fairly—it wouldn’t be difficult, but it’d be time consuming to create a system where in order to run this script, I want to make sure that someone has to make a request and someone within a different user group gets a Slack notification asking them for that request. We basically just bundle just those concepts together in a thing that you can configure with a couple of button clicks.
Beyang: Oh, that’s awesome. So, like, if I want approval, I can get approval, and upon approval, it will automatically run. I don’t have to, like, sign back in and, like, rerun with approval, or—
Ravi: Exactly.
Beyang: Okay.
Ravi: Yeah. Yeah, once Josh hits—or someone in the eng team hits ‘Approve’ in Slack, then it just runs automatically. So, that’s the high-level idea is just to make it as simple as possible to, like, broaden access to scripts and queries and things of that nature, while keeping it as safe as possible. And so that’s, like, the high-level basic concept of the product.
One thing I don’t want to get into right now, just in the interest of time, is we have a feature called Runbooks which allows you to, sort of like, orchestrate these things a little bit. So, let’s say you’ve built several scripts and you want to create something a little bit more complicated. You know, let’s say you have a—I’ll give an example—let’s say you have a delete user workflow where what actually you want to do is first from script that deletes the user from prod, that I’m going to run another script that hits the Intercom API, unsubscribes them, and then hit another script that, like, generates an archive of all their historical data and then finally sends them an email with an archive. I can build three or four different Airplane Tasks for each of those steps and I could stitch them all together into one Runbook where I can execute them in order, pass data between them, have conditional logic, all that kind of stuff, to that flow.
Beyang: So, you’ve built your—Runbooks is the way you compose these primitives that you’ve constructed. It’s almost, like, your, like, your own internal version of Zapier.
Ravi: Yeah, exactly.
Beyang: Awesome. What’s been, like, the… like, what do you think about, like, Airplane v0, like, the first thing that you shipped that you thought, you know, was going to be the product that people wanted, what are the big differences between that and what you have now? Is it largely the same or, like, are there any, like, major, kind of, realizations you had along the way?
Ravi: Yeah. The core of it is the same. I mean, we start with this idea of, like, how can we make it really easy to turn a script into an app, right? That was kind of the high-level idea. So, that core is still there.
Things that we have added not just features that we’ve added over time, but I always say the biggest mental model shift has been, you know, I—when we started Airplane, I would say that the primary thing that we were trying to do was make it possible to take things that can only really be as written scripts, right, like, things that aren’t super easy to model as a REST endpoint, or a simple SQL query, or a CRUD operation, and turn them into things that would be appified. Because he had so many of those Heap had so many of those. Heap is digital company; there were tons of these, like, long-running operations, these multi-stepper operations, sensitive things—
Beyang: Complex things, involved things.
Ravi: Yeah. That’s what we thought would be, like, the core use case of the product. And then it’s still very much what you can do with Airplane, but a lot of what people do with the product is really simple stuff that honestly, you could do in 20 other ways, right? Like, the update answer email address thing I just showed you, we’re not unique in giving you the ability to parameterize a SQL query and let someone run it over and over again. You can use tools, like, Retool to build a simple UI that hits a database and does that thing. You can use tools like [unintelligible 00:41:08] to have saved queries that people can execute over and over again.
And so, I remember, like, people started using the Airplane to do that kind of stuff, and then we added in the dedicated SQL and REST builders, the one I just demoed to you so that you don’t even have to write a script to do simple queries and stuff like that. And I remember asking people, like, “Why would you use Airplane for this? Why not use one of the other 50 other tools out there that are much more mature, much further along?” And they’re like, “Really, it’s just really easy to use Airplane.”
Beyang: [laugh].
Ravi: Like that was the whole idea. Like, the idea was like, you know, if you’re using any of these other tools, you have to configure a lot of stuff, or have to build UIs, or do all kinds of stuff that you don’t really care about. Whereas, like, for Airplane, we’ve surgically asked you to just concentrate on the thing that matters, the only thing that you, as the developer, need to bring to us because we can’t figure it out for you. We don’t know what query needs to get executed. You know that.
But all the rest of the stuff, the UI, the permissions and notifications, all that kind of stuff, we can just make some fairly intelligent assumptions about what that should look like. Like, it’s a webform to execute a function at the end of the day. We don’t ask you to drag-and-drop form fields on the page. We just say, “Hey, this is probably what this should look like.” And everyone’s just, like, “Yep, that’s fine.”
Beyang: That’s brilliant.
Ravi: And so, I think that was the idea was just, like, this super-clean separation of concerns of, like, “Hey, you care about the back-end logic. We’ll worry about everything else.” And that just appealed to people. And, like, the fact that it would take 30 seconds to build an Airplane, and maybe ten minutes to do it in another tool, that difference was actually pretty huge for people. Because the nature of these things, it’s stuff they don’t want to be worrying about, right?
Like, as a developer, you’re like, “I don’t want to do this thing over and over again. I want it off my plate as soon as possible.” And Airplane sort of fulfills that for you. It’s like, “Hey, we’ll get out of your way. And we’ll let you automate this thing. You send the link to your other teammate who needs to run this thing and then you’re done with it.”
Beyang: Especially if it’s like an internal app or tool, like, I don’t really care about the placement of the frickin’, you know, template fields. I just want, like, a form that someone can figure out it doesn’t have to be pretty, although I’m sure it, you know, looks reasonable in Airplane because you make reasonable assumptions. But, like, I don’t need to, like, design that thing. I just want something that someone can, like, type text into and then click a button.
Ravi: Right. Yeah.
Beyang: Okay, interesting. I think this, like, kind of brings up another interesting topic, which is, yeah, you started as a developer tool. Airplane still, I think, describes itself as a development tool, but I hear it increasingly mentioned in conjunction with, like, low-code or no-code tools like Retool. So—and maybe that’s, like, a common theme, too, because, like, you mentioned with Heap, too, that you start developer first—
Ravi: Yes.
Beyang: And you eventually became this, kind of like, low-code analytic solution. So, do you see Airplane kind of evolving into this, like, general purpose, like, low-code app builder, or is the DNA of the product and the company still, like, strictly a developer tool? Or maybe the boundaries are, like, getting blurred here?
Ravi: Yeah. I would say. So, I do think the boundary getting blurred all over the map, but I’d say for Airplane specifically, more so than anything else in this space, whatever this space even is, we think of ourselves as very, very much a developer tool, first and foremost. And to clarify, I mean, like, the people who build stuff in Airplane or developers, the people—the end-users of Airplane Tasks and Runbooks are often non-developers, more often than not. But we do not intend for non-developers to build things in Airplane.
Occasionally it happens, but I’d say at least 97% of everybody building Tasks and Runbooks in Airplane is a software engineer. And so, you mentioned, like, we get lumped in with the low-code, no-code stuff, I think, like—well, I think every piece of software is a low-code tools, in some sense, right, but—because you [couldn’t 00:44:46] code otherwise, but—
Beyang: Sure. [laugh].
Ravi: —aside from being pedantic, I would—
Beyang: That’s what—yeah. [laugh].
Ravi: Say that, like, I think the reason we get lumped in there is because a lot of people see the problem—so the problem fundamentally is that you have a small set of people in a company—maybe it’s the whole entity, maybe it’s even a subset of the entity—who have access to an operation, right? They have access to a thing that only they can do, and more people in the company need access. Sometimes those more people or other engineers, but usually it’s not engineers who need access to that thing. And so, a lot of other companies look at that problem and say, “How do we solve this issue? What we should do is we should build tools for the non-engineers so they can solve the issue themselves.”
And that’s a reasonable impulse, but our thing is, we’re, like, “Hey, a lot of the things that people need access to write against production data.” And, like, no matter how savvy your solutions eng team is, if they’re not part of the core software development workflow within your company, you’re going to be really reticent to give them write access to a production database, even if they’re like—like at Heap, everybody on our solutions eng team was very savvy, and very talented, and could easily have had write access to it. It’s just that they don’t understand, like—this—they don’t—they’re not in the day-to-day of the eng team so they don’t know, you know, exactly what the implications are of doing a—
Beyang: There a lot of pitfalls and [foot guns 00:45:57]. Like, things that you don’t realize… yeah.
Ravi: Right. And so, you want things that are going to touch production data and write against production data to be governed the same way you want the rest of your code governed. You want it to go through version control, you want to go through code review, all the rest of that stuff. And so, I didn’t really demonstrate this in the demo, but, like, everything in Airplane is governable via code. You can write scripts, put them in your codebase, but a YAML that represents a Task definition.
And that’s sort of the way we recommend you use it actually. The UI stuff [crosstalk 00:46:25] is easy to get started onto, but anyone using Airplane at scale should be governing it the way they govern the rest of their codebase. And so, that idea is very core to Airplane, that this is a developer tool because it requires—like, the valuable things about Airplane are of the ability to write against production data. And most companies really are only really going to have their eng team have the ability to do that. So, that’s kind of a hard, sort of, core requirement of it.
With Heap I think it was, we drifted over time because, like, the core end users of analytics ended up being a little bit different than what we thought they were, but I think we’ve seen enough data and we’re far enough along an Airplane where I think we see that there’s a—at least for a lot of companies that the engineering team is the right people to be selling to. There might be other companies out there which are better fits for some other approaches. But yeah.
Beyang: Got it. So, do you ever foresee a world in which, like, a non-engineer would use Airplane to write some piece of code? Say, you know, someone on the sales team wants to write some logic to, I don’t know, analyze some piece of the funnel, like, analyze the conversion rate of a particular set? Maybe that’s more of a Heap [laugh] use case, actually. Like, conceivably someone on sales and marketing or some other function might want to write some code that, you know, pulls some data and—or enacts some action. Is that something that, like, you think might occur in the future? Do you think it’ll strictly be, like, engineering teams are still, like, writing scripts and making apps for other people to run?
Ravi: Yeah. So, I think this is, like, another kind of—possibly, but, like—the answer is, like, possibly, but I think it’ll still be eng teams. And the reason I say that is because—so when you’re describing does happen, but I tend to see situations where non-engineers have, like, write access to company data is usually data that lives in third-party tools. So, there’s a lot of systems—there’s a lot of situations where, like, oh, so when the sales team has access to CRM data and they want to, like, have—you know, every time when the lead comes in, they want to have a Slack notification go out, or something like that. If what you’re doing is you’re stitching together third-party APIs, you can actually give a lot more freedom to people because, like, the downside is not as high, right?
Like, if somebody messes something up there, it’s not that big of a deal at the end of the day to, like, clean up CRM data or something like that. It’s not prod, right? Like, it’s not production data. And so, I think, like, that’s where tools like like Zapier and all that kind of stuff come in. And so theoretically, you could use Airplane to do the same things that those tools do, but they’re much more optimized for that use case, and they have, like, built their 5000 API integrations and all that kind of stuff that we’re just not going to do.
Where we see our sort of core differentiation and core, like, unmet value that were—like, unmet need that we’re solving is really around allowing you to, like, broaden write access to production data, like, core production data, in a way that safe, easy.
Beyang: Got it. Makes sense. And so, you’re focused on, you know, the engineer as your core user.
Ravi: Right.
Beyang: In terms of, like, sweet spot customer or company that will use Airplane, is it, like, any company that has engineers, that runs code in production, or are they’re like particular sectors or, you know, company sizes, where you’re particularly, like, resonant with [unintelligible 00:49:35]?
Ravi: Yeah. I would say in the long-term, yeah, we want every software team that—every software team backing a cloud product to be able to use Airplane. If you’re building on-premise software, the way Airplane works doesn’t make a whole lot of sense. But yeah, if you’re building a cloud product, and that doesn’t necessarily mean a SaaS company, it could mean, like, the Chase Bank mobile app, right? Like, anytime you’re, sort of like, responsible for a piece of cloud software that needs to have these sorts of one-off maintenance requests happening and on-call Runbooks being executed all that kind of stuff I think Airplane could fit.
That being said, like, where we’ve done really well so far in the sort of short lifespan of the company today, it’s mostly small to midsize SaaS companies, FinTech companies, marketplace companies, healthcare companies. Basically companies that are, let’s call it between—like, less than maybe 500 employees, usually. So, they’re small enough where they haven’t necessarily built up a ton of internal tooling yet, they’re small enough where they’re still iterating super fast and the internal tooling needs are evolving really quickly. And so, as a result—and if they’re fast growth then, like, that needs are even more acute. So, you know, if you take—like, you’re some 100-person, SaaS company with a 15-person solutions engineering team, and a 10-person sales team, or whatever, and 20-person eng team, and there’s, like, a massive backlog of product to build, and you have engineers just, like, one-off helping with every customer onboarding, and with, like, answering random tickets and stuff like that, that’s, like, the sweet spot for Airplane, right, because we can just say, like, “Hey, you can get all this off your plate as the eng team, empower your customer-facing teams, and, you know, accelerate your roadmap, potentially.”
Beyang: Cool. What’s kind of next on the roadmap? Anything you’re looking forward to in the upcoming months and year?
Ravi: Yeah. So, there’s quite a few interesting things we’re working on. I mentioned briefly that the way we want people to use Airplane is the way that they—like, as similar to there are typical engineering workflows as possible. So, writing a Python script locally, and testing it out locally, deploying it to Airplane, and then version-controlling it, and testing it, and all that kind of stuff. Like, that’s kind of the way we want people to use Airplane.
Where Airplane is today versus where we want it to be, there’s still a bit of a gap there, so we’re doing a lot of iteration on the developer workflow. And we want to get to the point where, like, matches kind of what you’re used to, from really, like, best-in-class developer tools, like, Versel or something like that, just make it really, really simple and, like, not having to introduce a whole lot of new concepts into how to use the products. But even today, it’s pretty clean and that’s what people love about the product is just the developer experience. So, trying to get it from good to great, really. So, that’s one big area of investment.
Another big thing is, like, we’re really trying to deepen the set of things that are possible with Airplane. So, I very quickly showed you, kind of like, what we call a Task in Airplane, which is, kind of like, a single business function that needs to get executed. And then I mentioned, like, you can do what’s called a Runbook, which you can stitch multiple Tasks together. And so, you can do, like, pretty simple linear flows, of, like, linear composition of, like, five or six things in a row. There’s even some conditional logic you can insert into there, but we’re going to greatly expand the set of things as possible there.
So, for example, we’ll have the concept of loops, where you can say, “Hey, let’s take the output of this SQL query—like, all 100 rows in this output—and then execute this Task 100 times for each row in that output or something like that.” So, you’ll be able to do that. We’ll have, like, parallelization so you can run multiple things at the same. Time, we’ll have, like, the idea of, like, more complex, like, human-in-the-loop logic, so being able to say, “Hey, this is a ten-step process. These first four steps can be executed by anybody, but this fifth step is really sensitive. It can only be done by somebody on the X, Y, Z team.” And so, there could be a handoff concept happening in the middle of it. So, that kind of stuff as well.
Beyang: It sounds like that’s even on the track toward constructing these, like, general-purpose data pipelines of sorts because, like, you could have one thing that emits, like, a bunch of things, and then something else that comes along and consumes the output of that and, like, do you foresee that as that being a potential evolution here?
Ravi: Potentially. And even today, people use Airplane for really simple data pipeline type things. We don’t see ourselves as, like, an Airflow competitor or something of that nature.
Beyang: Okay.
Ravi: So, I think, like, there’s—when you’re doing really sophisticated things, like, a high level of scale, I think it’s better to just use, like, Airflow, or Luigi, or whatever, for that kind of stuff. But, like, there’s a—the thing we see with Airplane is like, a lot of people using Airplane, like, really simple stuff. Like, really simple pipelines that, like, honestly don’t require a lot of the complexity or configurability of something like an Airflow. And so, in those situations, like, yeah, we do intend Airplane to be, like, a simpler replacement for stuff like that.
Beyang: Okay, got it. Got it. Do you have any plans, like, investing more into that development environment—or sorry, not the—you don’t have a development environment, but, like, the editor that you showed off in the GUI? You mentioned, like, the preferred way of using Airplane right now is you write the script in whatever editor environment you have, and then you upload and, like, Airplane is strictly a runtime, but I feel like when you’re doing that demo, it’s almost, like, a short leap to—you already have autocomplete you already have syntax highlighting. You know, another thing that you see with a lot of these new, kind of, cloud-based programming tools is a developer environment of some sort. Like, any plans to do that, or do you think you’ll stick to just, you know, providing the runtime and not really getting into the development side at all?
Ravi: Yeah, so in terms of, like, the development environment, honestly, we’re of two minds on it. I think right now, I think we’re more likely to build, like, a VS Code plugin than we are to, like, build, like, a full-fledged in-browser, IDE or whatever you want to call it. Though, I think, like, it’s kind of—when I say we’re of two minds, like, on one hand, we have this idea of what Airplane—of how you should use Airplane, like, this sort of like, quote-unquote, “Proper,” way to do it, but there is friction with sort of like setting up your local dev environment to be Airplane compatible. And so, the in-browser stuff is, like, the cleanest onboarding flow, right? It’s, like, all in one place, you don’t have to, like, go do a bunch of stuff with your CLI and fiddle with that.
And so, I think, like, probably will do that as well, at some point; it’s just, like, a question of prioritization. And so, like, I think, like, making these, sort of like, local dev experience better and better and better gets you, like is the thing that drives more expansion and retention of Airplane. Like, it’s the thing that makes sure that Airplane works really well at scale in a company and that it’s easy to onboard new developers onto and all that kind of stuff. But it’s not the thing that, like, delivers that magic aha moment as efficiently as possible, which the in-browser stuff does better. So, like, you know, you kind of have to have both, in some sense.
Like, yeah, I mentioned Versel earlier as a tool I admire. When you first sign up for Versel, like, it’s actually all in-browser, like, the way they get you up and running with the products. But then, like, you really have to use a client at some point to… use it, sort of, x scale in a real organization. So, we’ll strike some balance there, I think.
Beyang: Interesting. Interesting. Are there any users, like, asking for features like that, or just, like, other features that, like, don’t quite fit into—because this is, like, a constant tension, I feel with a lot of companies, especially ones that are early. It’s like, you come to the table with, like, some preconception of how your product ought to be used, but then, you know, your early users, especially if you have good ones, they use it in all sorts of creative ways that you don’t anticipate. Are they’re, like, different camps of users right now that you’re trying to satisfy? Or is it more or less, you know, like that, you know… they don’t want the development environment, they just want the kind of simple runtimes or really simple actions and that’s the path forward.
Ravi: Yeah. I mean, people are asking for all the above. I would say, like—and all of it, I think does fit on the path of things that we want to build. I would say, like, the places where people try to push the product where we’re actually kind of not necessarily trying to go there, I alluded to earlier, we’re not trying to be Airflow, right? We’re not trying to get super complicated bespoke data pipelining workflows.
I think, like, it’s—or, like, for another example, we’re not necessarily trying to allow people to build, like, super pixel-perfect internal workflows. Like, you know, for most companies are, like, “Hey, this is some random internal tool I use it to, like, make it quickly and move on.” But for a small subset of companies are, like, “Actually, this internal tool is really important. Like, this internal tool needs to—you know, is getting run 50,000 times a day by a team of a bazillion people and I need to make sure that it’s really, really, like, done in a way that can’t have any deviation or error or anything like that.” And so, to make sure, like, it’s perfect, like, if that’s what you’re trying to do, like, you should probably just write it in pure software or use some open-source framework that’s more extensible or something like that.
Because with Airplane, like, we’re really optimized around speed and simplicity. Like, we’re going for the, for that long tail of stuff in your organization that you don’t want to build into your product, that you don’t want to write, like, code from the ground up for, that you want to spend as little time on as possible. And so that’s, kind of like, the niche. But, like, inevitably, when you’ve started using Airplane, you have 50 Tasks built into it, you’re going to want to push the boundaries of what it’s capable of, and you’re going to want to say, like, “Hey—” like, [Bobby Blass 00:59:03]—like, “Hey, can I, like, invoke an Airplane Task through an API and then have it be sort of like an end-user facing thing so our users can, like, hit a button that [crosstalk 00:59:11] Airplane task.” And I’m like, “You can if you really want to, but that’s not what we’re trying to do.” We’re not supposed to your application back-end, right? Like, we’re for internal stuff, right? And that’s, kind of like, the directions in which people try to push the product that aren’t necessarily where we’re trying to go.
Beyang: Yeah. That’s fascinating because that’s almost, like… this thing was built for things that you didn’t want to put in the product; now people are trying to build parts of their product and on top of—
Ravi: Yeah. And they never start there, right? They start with the stuff that it’s intended for, I mean, that’s why they signed up for it; that’s the marketing message that resonated. But then they’ve put, like, 20 things in there, like, and they’re like, “Well, but maybe I could do this more other thing in here.” Right?
Beyang: And the functionality is already there. Why, you know, like—
Ravi: Exactly. Yeah.
Beyang: Write it—some—yeah. Yeah, I know how that goes. Cool. So, we’re almost at the end of the hour here. Thanks again so much for taking the time. One last question. If folks are listening to this and want to check out Airplane, what should they do?
Ravi: Yeah, so we’re a self-serve product with a free tier, so—pretty generous free tier; we can do quite a bit. So, you can go to airplane.dev—D-E-V—and just sign up for a free account. You can also email me personally, [email protected]—R-A-V-I at airplane.dev.
Beyang: We’ll drop a link in the [show notes 01:00:29].
Ravi: I’m always happy to chat and, you know, go through a demo, answer any questions you have, all that kind of stuff.
Beyang: Cool. Awesome. Well, my guest today has been Ravi Parikh. Ravi, thanks for coming on the show.
Ravi: Likewise, thank you so much for having me on. It’s been a lot of fun.