Ravi Parikh is the Co-Founder of Airplane. He joins the show to talk about his company. Airplane is a developer-centric approach to building internal UIs and workflows. He begins by explaining some of the common issues that "Airplane" solves. He also shares how his company started and many more!

Charles Wood:

Hey folks, welcome back to Developer Toolbox. I'm your host, Charles Max Wood. And this week we're gonna be talking about airplane.dev. Now it's a pretty cool tool. You can build internal UIs, you know, think workflows or dashboards or things like that. I'm here with Ravi. Ravi, do you wanna say hello?

 

Ravi Parikh:

Hey, thanks so much for having me on. Yeah, I'm Ravi. I'm one of the co-founders at Airplane. So happy to chat about what we're building and a little bit about the background and all that kind of stuff.

 

Charles Wood:

Yep, absolutely. So I've kind of in a kind of quick thumbnail giving people some idea of what we're talking about, but I mean, what is the problem you're trying to solve?

 

Ravi Parikh:

For sure. So high level, the problem we're trying to solve is that if you think about almost any software company, whether you're building SaaS software, some finance app, you're building. streaming service, whatever it might be, there's a fair amount of work that goes into building internal tooling. And by internal

 

Charles Wood:

Mm-hmm.

 

Ravi Parikh:

tooling, I mean software that's not customer facing. So you have to build these dashboards or admin panels to let your support team read and write against customer data. Maybe you need some sort of like internal workflow that defines your customer onboarding flow or whatever. All those things end up taking up engineering time and sort of taking away engineers from sort of core product development. And so the idea behind Airplane is really to make that internal tooling work as efficient and as fast as possible for developers. So the way it works is you write small amounts of code to define the key internal workflows or operations that your business has to do. Let's say someone needs to be able to look up a user, extend their free trial, delete something from the database, do some sort of migration, whatever it might be. You define those things, deploy them to Airplane and we'll sort of overlay things like UI notifications, permissions, audit logging approvals, all the things

 

Charles Wood:

Okay.

 

Ravi Parikh:

it takes to make these like internal operations viable within a business of any scale.

 

Charles Wood:

Yeah, that makes sense. A couple of things that kind of stood out to me, one of them is that on top end devs, for example, I've been building my own admin panel. And a lot of that kind of sucks.

 

Ravi Parikh:

Yeah.

 

Charles Wood:

I'm fussing with the UI. I'm figuring out what's here or there, whatever. So the idea of being able to just effectively define, hey, when somebody does this, do this in the database.

 

Ravi Parikh:

Right.

 

Charles Wood:

When somebody needs to do this kind of a thing, go through this workflow and progress the object through different states or whatever. A lot of that really appeals to me. One other thing that I have just been struggling with, to be perfectly honest, is putting together a dashboard that's like, hey, these are the key metrics that we're looking at for the next three months and

 

Ravi Parikh:

Yeah.

 

Charles Wood:

making it real easy to find. And Granted, some of that is just because the metrics come out of systems that don't make it easy to get the metrics out of. But to a certain extent, it's like, okay, I have to pull in a graphing library and I have to pull this in and I have to pull that in, right?

 

Ravi Parikh:

Right.

 

Charles Wood:

That's the appeal to me. In talking to you before the show, I've seen tools that are supposed to do this with no code, right? It sounds like yours is more geared toward, hey look, you've got people who are experts in the subject matter, who can come in and write some code, but then they just define the pieces that have to be defined that are specific to you, and then the rest of it, yeah, they don't have to fuss with the UI, they don't have to deal with the ins and outs of the rest of it because they can effectively, you know, tell us how to fetch the data and we can do the rest of the work.

 

Ravi Parikh:

Right. Yeah, I think you've described it really well. Yeah, the way we see it is that those admin panels you're trying to build, those internal metrics dashboards, the basic things you're trying to do look very similar to what every other company is trying to

 

Charles Wood:

Mm-hmm.

 

Ravi Parikh:

do as well. It's probably

 

Charles Wood:

Yep.

 

Ravi Parikh:

the same tables and charts and graphs and web forms and whatnot that need to kind of all live in one place. The difference is the thing that you know that your business knows is the specific queries, the specific API endpoints,

 

Charles Wood:

Right.

 

Ravi Parikh:

the specific logic of how certain workflows need to work. What we ask of you as a platform. just do that specific work that's bespoke to your business. Just tell us what's

 

Charles Wood:

Mm-hmm.

 

Ravi Parikh:

the specific data or query or whatever needs to show up over here.

 

Charles Wood:

Right.

 

Ravi Parikh:

But we'll provide the component library. that we'll take care of layout, we'll take care of UI, we'll take care of user access controls and all that kind of stuff on top of all that stuff you're building, so you don't have to mess around with all that stuff. You kind of alluded to no code. We're much more of a developer platform. The way we kind of see it is the best way to define logic is code. The best way to say

 

Charles Wood:

Mm-hmm.

 

Ravi Parikh:

how things should work is code. And so we sort of sell to developers, we say we're gonna give you a set of building blocks that you can write code around to sort of make it look the way you want and

 

Charles Wood:

Right.

 

Ravi Parikh:

whatnot.

 

Charles Wood:

Yeah, one other thing while I was browsing your website was that you do have some connectors to other things that a lot of us use, like Stripe as an example. So I'm running my business on Stripe. I think a lot of other businesses on the internet run on Stripe. So yeah, having that tie in and just being able to say, hey, I just want this data from this kind of a thing to do this.

 

Ravi Parikh:

Right.

 

Charles Wood:

So

 

Ravi Parikh:

Yeah.

 

Charles Wood:

I'm always curious to know what prompted this, right? Where did this idea come from? Everybody has a different story. Some people started with something completely different. Other people, this was the idea from the start. What's your story?

 

Ravi Parikh:

Yeah, so yeah, airplane definitely came from a personal pain point. So by way of background, we started airplane about two and a half years ago in 2020.

 

Charles Wood:

Mm-hmm.

 

Ravi Parikh:

And before that, I co-founded a different company called Heap, which is an analytics tool. And

 

Charles Wood:

Mm-hmm.

 

Ravi Parikh:

so... I started Heap in 2013, helped grow it to about 200 people over the course of the next seven years there. It's still around today. It's roughly doubled in size since I left

 

Charles Wood:

Mm-hmm.

 

Ravi Parikh:

and it's doing quite well. But basically, Heap was an analytics company or is an analytics company. And in the course of scaling it, we ran into all these problems around internal

 

Charles Wood:

Right.

 

Ravi Parikh:

tooling. And so people would often email our support team and say things like, hey, I installed the API wrong and my data is all messed up. Can you fix it for me? Or I accidentally

 

Charles Wood:

Oh man.

 

Ravi Parikh:

made two different Heap instances for my company and I need to combine data into one place or I want to connect my heap data to Snowflake and I'm not really sure how to make that ETL connection work

 

Charles Wood:

Right.

 

Ravi Parikh:

or whatnot. And a lot of these like one-off use cases, what would end up happening is that would end up hitting our solutions team or support team. They would usually have to escalate that to engineering. Someone from engineering would have to get involved, like write some script or some query

 

Charles Wood:

Mm-hmm.

 

Ravi Parikh:

and then like run some job and like wait for that to finish. It's a data tool. So like sometimes

 

Charles Wood:

Right.

 

Ravi Parikh:

those scripts would take hours to run. Then you'd have

 

Charles Wood:

Don't

 

Ravi Parikh:

to

 

Charles Wood:

break the

 

Ravi Parikh:

get

 

Charles Wood:

database,

 

Ravi Parikh:

back to the support

 

Charles Wood:

don't break

 

Ravi Parikh:

team

 

Charles Wood:

the

 

Ravi Parikh:

and

 

Charles Wood:

database.

 

Ravi Parikh:

say... Yeah, of course. And that's also, I've had a couple close calls

 

Charles Wood:

Yeah.

 

Ravi Parikh:

or not so close calls a few times. And so that is just like a, not a great status quo. You have constant interruptions, constant back and forth within the company

 

Charles Wood:

Yep.

 

Ravi Parikh:

to resolve customer issues. You have really unsafe operations happening like you mentioned, like don't break the database. And we could never really get those out of the hands of engineering and turn them into like good, solid, enterprise grade,

 

Charles Wood:

Right.

 

Ravi Parikh:

safe internal tools that like... anyone can use within the company. It just, you know, there was always just like a mountain of this kind of work to do. And so the idea behind Airplane was, you know, we noticed that pattern. I noticed that pattern over at Heap. My co-founder at Airplane, he had a similar story to me. He was CTO of a company called Benchling before, which is like a life sciences SaaS company, had the same set of problems over there. And so me and him were kind of talking when we had left our previous companies and said, you know, this problem was at both of our companies, it's probably at other companies too. And so we interviewed. friends of ours, engineers, non-engineers, at a variety of companies from small startups all the way up to big public companies and got a sense that no matter how big a company is, there's always this huge long tail of stuff that is just really messy internally. And a lot of that stuff is really similar from company to company. There's the same kind of workflow constructs that need to exist, the same kind of permissioning challenges, auditing challenges, UI challenges that exist around internal tooling. And our thought is if we can build the right set of building blocks so that as an engineer, you don't have to worry about any of that stuff, you just worry about the logic of the operations, we could save a lot of people a lot of time. And

 

Charles Wood:

Mm-hmm.

 

Ravi Parikh:

so that was the whole... thesis of airplane, the core idea has stayed pretty similar since day one of airplane. But I think the reason we haven't had to pivot a whole lot is because we had this very clear idea in our own heads of the pain that we had sort of spent the last few years experiencing.

 

Charles Wood:

Makes sense. I'm curious what you used at Heap or whatever. I mean, you know, it sounds like you had to solve these problems, so

 

Ravi Parikh:

Yeah.

 

Charles Wood:

what do people do if they don't have an airplane to fix it for them?

 

Ravi Parikh:

Yeah, very good question. I have seen all kinds of things that people throw out the problem. What we did at Heap was kind of a combo of things. So one is we built a Slack bot internally. And basically the way the Slack bot worked is there was like a set of predefined commands that were things like extend free trial or like, you know,

 

Charles Wood:

Oh, okay.

 

Ravi Parikh:

increasing the rewards allocated to this customer. And they would basically, when you hit that Slack command, it would like spin up a container and like run some script in some environment. That worked okay, but it took a while to build that slack bot and make it kind of work. It went down all the time. There's a lot of internal maintenance around it. And adding new commands to it was really painful because ultimately that's not Heap's core competency to maintain and build that Slackbot. It was just something one person built as a side project and it ended up becoming a too valuable piece of the internal operation. So we did that. We also had a couple like one-off bespoke tools we built for really common internal use cases and stuff. And then there was a lot of stuff that honestly, we just didn't build out. Like if there was a certain thing that happened. frequently, but not frequently enough, it might just stay that some random infrastructure engineer had like built a script and they're the person who owned it. And every time that issue happened, it just got escalated to them and they had to SSH into some production server and run some script. Like that was just a status quo for so many other operations. So it was, it was honestly a fairly messy time consuming set of ways of dealing with that problem.

 

Charles Wood:

That makes sense. I guess the other question that I have related to your origin story and kind of where you're at now is what was it that made you think that there was kind of a common solution to this because yeah, I mean I guess some of the fundamentals are the same but I mean I've worked at a lot of different companies that did a lot of things a lot of different ways, right?

 

Ravi Parikh:

Yeah.

 

Charles Wood:

And so yeah, I'm trying to get my head around, okay, what would make me think, huh? If I have access to their database and their Stripe account, I can do these kinds of things for them.

 

Ravi Parikh:

Yeah, it's a good question. I think there's a couple of things that made us kind of think that this could turn into an actual like, repeatable kind of like SaaS product. One is that so my co founder, Josh, had a much better solution at his company. So at bench laying,

 

Charles Wood:

Mm-hmm.

 

Ravi Parikh:

they essentially built something internally that was kind of like a proto version of what we ended up building an airplane. So there was already a little bit of precedent there where I mean, he had taken a couple quarters and like built a system. It wasn't perfect. There's a lot of things that airplane we've done to sort of like build upon those concepts, but he already had a little bit of a sketch of a solution to this idea that worked pretty well internally over there. Two is we actually kind of saw that at some bigger companies too. We, when we were interviewing people at a variety of companies, we talked to some folks at Stripe and then

 

Charles Wood:

Mm-hmm.

 

Ravi Parikh:

also Facebook and learned that both of them had internal systems that kind of looked like airplane or kind of looked like what ended up

 

Charles Wood:

Okay.

 

Ravi Parikh:

becoming airplane. And so we were basically, when we were. we were kind of prototyping this idea. We kind of had this little pitch deck with a bunch of mockups of like, here's what airplane is gonna look like. And when we showed it to the people at Stripe, they're like, oh, we have that already, or we have something like that already.

 

Charles Wood:

nice

 

Ravi Parikh:

So when we kind of heard that, we're like,

 

Charles Wood:

yeah

 

Ravi Parikh:

okay, a couple of best in class companies have built this already and have seen a lot of good effects internally. And it seems like when we pitch it to people who haven't built it internally, they're like, oh, that'd be pretty nifty if we had that. That kind of gave us some confidence that there is sort of a solution that could be built.

 

Charles Wood:

That sounds awesome. And I really kind of identify with that, right? Because it's, you can see it in action, right? You have some validation, right?

 

Ravi Parikh:

Yeah.

 

Charles Wood:

So yeah, so you get in, you start building this. I mean, what's that experience been like? Has it been pretty smooth? What hiccups have you seen?

 

Ravi Parikh:

Yeah, it's definitely been, you know, I think the core ideas remain the same, but there's still been like a ton of learnings on the way there. And so it has not necessarily been like a direct smooth path. You know, we're doing quite well now,

 

Charles Wood:

right.

 

Ravi Parikh:

but took probably a year or two to really find that key product market fit. I would say like some of the learnings along the way, I think we had a sense that, you know, if we solved this problem and said, Hey, this is a solution that kind of like allows you to sort of create internal tools very easily and all that kind of stuff. That would be kind of enough. I think one thing we sort of learned along the way was that it was key to get the developer experience and the speed and the time to value to be really, really, really good. And so obviously everyone wants their speed and the developer experience to be good. No one says that those are unimportant things, but we kind of thought like, okay, you know, if there's a few days of setup time, that's not a big deal. But what we actually found was that the nature of a lot of these long tail internal tooling problems is If they were really important, they already would have been put on the roadmap in some sense. So they're kind of like just below that level of importance where you're devoting a lot of engineering time and resources to it. And so if you're going to get someone to take that from below the line to like over the line of like, okay, now I'm going to devote time to it now that airplane exists, it has to be like a no brainer. Someone has to be able to look at the docs or look at the marketing material or whatever and say like, you know, if I sign up for this product. within 30 minutes, I'm going to have something actually value generating for my business. And so we put in a ton of reps into making that work, but it took us like maybe half a year to even realize that that was like, uh, you know, a priority zero problem for, for us as a product. So now it's at the point where you can sign up for airplane and most people, obviously everyone's infrastructure and needs are a little bit different, but most people can get up and running really, really fast. And we're kind of proud of that, but it took us a while to realize that that was even just a really important thing to do.

 

Charles Wood:

Gotcha, so you mentioned that you wanted to make it kind of a no-brainer case, right? So

 

Ravi Parikh:

Yeah.

 

Charles Wood:

who are your no-brainer cases, right? If I'm a developer and I'm coming to look at Airplane, what's, yeah, what kinds

 

Ravi Parikh:

Yeah.

 

Charles Wood:

of people are going, oh, this is a no-brainer?

 

Ravi Parikh:

Yeah, I would say like our like our sort of bullseye for like when, you know, someone looks at airplane things like, okay, I definitely need this is typically if you're in a situation where you're an engineer and you're getting pinged multiple times a day to like run a script or a query on behalf of someone else. And so if you're like, I already have this like doc somewhere over here with like a bunch of saved queries to like, you know, update the user's email address or whatever, or I already have like this folder of scripts sitting on my laptop or I'm running these over and over again to do these like. common, I don't know, on-call run book type use cases or whatever. If you're in that situation and this is like just an increasing interruption level, like the airplane pain point will resonate with you. And the time it'll take you to take those like one-off scripts or one-off queries and turn them into shareable apps is really, really fast. So you can literally sign up for airplane, take some Python script you have sitting on your laptop, installer command line tool, run the deploy command. And now you'll have an auto-generated UI that sits in front of that script that you can share with someone else on your team. So it's literally five to 10 minute process to go from like, this is a thing that interrupts me five times a day to like, this will never interrupt me again. So like that's kind of like, um, when people are in that situation today, that's when they sort of see what we're doing and kind of have that aha moment of like, this is worth doing.

 

Charles Wood:

Yeah, that makes sense. It's kind of funny because sometimes it works out to where you build the UI and then you never get bothered about it again. And sometimes

 

Ravi Parikh:

Yeah.

 

Charles Wood:

what happens is, this is so nice. We need it to do this, this, this, this, and this.

 

Ravi Parikh:

Yeah, true.

 

Charles Wood:

But it sounds like you provide enough of the infrastructure to where when I run into that, I can either modify the script that already runs or I can tack in some other thing and give another UI.

 

Ravi Parikh:

Yeah, I mean, that's exactly it. The, the, the real, if I zoom way out, the goal of airplane is to make repeated work turn into one-time work, right? Like you're an engineer and like, I have to keep doing this over and over again, just to a once in airplane and you're good. Even if you get the next request, like, you know, there's usually not an infinite well of requests there at some point, you're going to

 

Charles Wood:

Right.

 

Ravi Parikh:

have built most of the key operations of your business

 

Charles Wood:

Yep.

 

Ravi Parikh:

into.

 

Charles Wood:

Yeah, that's very true. Well, and even some of the dev tasks and stuff that you run on a routine basis. I would assume a lot of that

 

Ravi Parikh:

Yeah.

 

Charles Wood:

is scripted as well, so you could do a lot of the same things. And so then it's,

 

Ravi Parikh:

for sure.

 

Charles Wood:

hey, I need to know what the status is on this or that, and you're off to the races. The other thing is that if it's code, right? And this is the trick that I run into with Zapier and things like that is.

 

Ravi Parikh:

Yeah.

 

Charles Wood:

I'm limited to what somebody's built. If somebody hasn't said, here's how you get this information out of that system, I am out of luck. I mean, I can go write my own integration and I can deploy it to Zapier and I have done that before and it's a giant headache.

 

Ravi Parikh:

Yeah.

 

Charles Wood:

With this, it sounds like I'm capable of importing an HTTP library. I'm capable of running the query. If there's not already like a fully fledged, hey, this is a fleshed out API library for this service, and then I could just write the code and make it do what I want.

 

Ravi Parikh:

Yeah, and that's what most of our users do. We see the fact that it's all in code as like one of the key features of the platform. People put some really bespoke stuff in Airplane that we probably never would have written integrations for. And so, yeah, for sure.

 

Charles Wood:

So I guess the other question that I have with this, and this is just out of the blue, something that came into my head, was that I wind up helping people with different systems, right, on their end. And a lot of times I'm basically exporting my process and my tools to them. Is there a way to do that inside of Airplane where I could essentially say, hey, this is the dashboard that I've built for my system X, you know, here. You know, here's the code, the script, the setup. You know, I just, you know. You have one too

 

Ravi Parikh:

Yeah.

 

Charles Wood:

now.

 

Ravi Parikh:

Yeah. So, so the way airplane works is like the code you write for airplane, it's just code you own. So what people typically do is they'll put like, they'll create a separate repository for their airplane code, or maybe, maybe they put like a folder in their mono repo or something like that. And so whatever method you use to share code is the way you'd use to share airplane code as well. So if you're like, I have a GitHub repo with my airplane dashboards and whatnot, I can actually just like, you know, fork that repository or add someone as a collaborator on it or something like that. And they'll be able to see the airplane code as well.

 

Charles Wood:

That makes sense. So what languages do you support?

 

Ravi Parikh:

Um, really anything. So we have like native support for JavaScript, Python shell scripts. Um, we have some dedicated builders for like SQL, or if you're making GraphQL or REST endpoints or stuff like that, but if using any other language, we actually have like a way to just take a Docker container and do whatever you want inside it. So we actually ourselves use Go internally. There's no Go builder for airplane, but it's not really a big deal because you can just use, just wrap it in Docker container.

 

Charles Wood:

Yeah, a lot of the stuff that I do, I do in Ruby. And it's not that, I mean, our biggest show's JavaScript. I spend a lot of time writing JavaScript, but I've been doing Ruby forever. And so it's just

 

Ravi Parikh:

Yeah.

 

Charles Wood:

really easy for me to kind of think it into Ruby. And so yeah,

 

Ravi Parikh:

Yeah.

 

Charles Wood:

I like that. I can just put it in Docker and it does the right thing.

 

Ravi Parikh:

Yeah, exactly.

 

Charles Wood:

Cool. So, um. Yeah, so I guess the other question is, how do I get started, right? I mean, do I just sign up for an account, push code? Is it that simple?

 

Ravi Parikh:

Yeah, more or less. Yeah, so basically you can go to airplane.dev, D-E-V, and sign up for a free account. So we have a free tier, which is pretty generous, but then there's paid tiers above that. There's a self-serve plans and then enterprise plans and whatnot, your typical SaaS pricing. But yeah, you can just get started right away. The other nice thing about Airplane is even if you're using it for more secure use cases or things like that, you can self-host as well. So it's not purely just a SaaS platform. You can

 

Charles Wood:

Okay.

 

Ravi Parikh:

kind of host it in your own infrastructure as well if you need to.

 

Charles Wood:

Right, so if you have like a HIPAA requirement or, I've spent a lot of time in education here in the US, FERPA, right,

 

Ravi Parikh:

Yeah.

 

Charles Wood:

protecting student

 

Ravi Parikh:

Yeah.

 

Charles Wood:

data. Right, so your PII lives on your system, right, airplanes providing you with the infrastructure that way. And

 

Ravi Parikh:

Yeah.

 

Charles Wood:

since you control where the data lives, you have, it's easier to comply with whatever.

 

Ravi Parikh:

Right. Yeah. And so we have plenty of like healthcare customers, financial services customers, ad tech customers, so on and so forth.

 

Charles Wood:

Cool. Well, what about you? I'm a little curious. So, where you based and what's your background?

 

Ravi Parikh:

Yeah, for sure. So I live in New York. Our company is kind of split. We're remote first, but I have a co-founder who lives in San Francisco. And then we have people here in New York, in SF, in other cities in the US and also internationally as well. So we're kind of all over. In terms of my personal background, yeah, like I mentioned, I previously co-founded another company called Keep. So last. more than a decade have been basically, you know, working on SaaS companies more or less. And so, engineer by background, but at this point, more focused on kind of building out the business and things like that. So I write a lot less code these days than I would like to. But yeah, that's a little bit about me and where we're based.

 

Charles Wood:

Cool. I also want to ask really quickly about the remote first. It seems like a lot of the companies that I talk to that are remote first are mostly remote, it kind of happened over COVID. And they didn't start that way, and they still don't really. operate that way?

 

Ravi Parikh:

Yeah.

 

Charles Wood:

I guess they do, but they try and make it look as much like you're in the office as possible. So do you have any pointers for people there? It also seems like something like Airplane would be especially helpful for that because it allows you to kind of have a common interface where you do your stuff.

 

Ravi Parikh:

Yeah, that's a really good question. To be honest, I don't have any magic bullet answers. One thing that's a little bit serendipitous is my previous company, Heap, was not remote first. We had a pretty big remote contingent in our company even before COVID. So we had about half our engineering team was international and kind of based not just remote, but also in all kinds of different time zones and stuff. So we had to get very good at sort of writing things down, keeping... a good sort of culture of asynchronous collaboration where you might only have two or three hours of overlap with someone you're

 

Charles Wood:

Right.

 

Ravi Parikh:

working on a project with a day. So you got to be really good about not creating a situation where you're waiting 24 hours to get a pull request reviewed or something like that. So we had some growing pains here in the early years of HEAP, but by the time I left, we had a really good rhythm there of how we kind of worked remotely, how we communicated remotely, how we wrote things down. And then we also just did a lot of in-person stuff as well. We did like annual, the whole company gets together, every quarter teens get together, things like that. And so we're doing kind of similar stuff over here at Airplane. We started Airplane kind of like you mentioned in the middle of COVID pre-vaccines.

 

Charles Wood:

Right.

 

Ravi Parikh:

It was 2020. And so we had no real option other than to be remote

 

Charles Wood:

Right.

 

Ravi Parikh:

from day one. Once things started opening up a little bit more, we do have a small office in San Francisco and New York where we have, you know, more than a few people in both cities. So people do come in optionally. It's not a requirement. I'm taking this call from home as you might be able to see in the background. But yeah, that's, that's kind of how we've. sort of done it and it's worked pretty well. Just be put a lot of emphasis on writing things down and things like that.

 

Charles Wood:

Yeah, cool. Well, I think there are some nuggets there, yeah, just with the way you communicate and making sure that everything's written down and well covered and stuff like that. I guess the last question is really just, yeah, if people wanna get started, they sign up for that free account, they start pushing their code up. I mean, what kind of results are people getting, right? What?

 

Ravi Parikh:

Yeah, for sure.

 

Charles Wood:

What are you seeing?

 

Ravi Parikh:

I, yeah, I would say like, um, you know, at this point we've been around for a couple of years, we have, uh, you know, a couple of hundred paying customers and then like several thousand free customers as well. Um, I think the things that we've seen in our most successful customers is that they'll usually start out with, you know, these five or 10 scripts or queries that represent some like really common kind of like annoying, like the most annoying use cases.

 

Charles Wood:

Right.

 

Ravi Parikh:

So they always kind of start a little bit small, but what ends up happening Kind of what you said earlier, which is like, once people see that like, Oh, wow, this thing that's been like this internal pain point for us for months is now

 

Charles Wood:

Mm-hmm.

 

Ravi Parikh:

all of a sudden this like really clean UI that I can just click a button and trigger. I wonder what else could go there. And so everybody,

 

Charles Wood:

Right.

 

Ravi Parikh:

whether they're on the engineering team or on the non-engineering team starts thinking, Oh, here's some things I'd like to live there as well. And so you quickly see this explosion from it's a thing that a few users use with a few scripts to in some cases, hundreds or even thousands of different operations that sort of exist in there. And so that's usually what happens in our most successful customers is they just sort of see an explosion in like airplane being a landing pad for all these kinds of repeated

 

Charles Wood:

Mm-hmm.

 

Ravi Parikh:

internal workflows and operations. So yeah, I would encourage anyone to just give it a start, start for free, try it out, see if it fits the pattern of how you guys work at your company. And if so, you might find there's a lot of unexpected use cases for it.

 

Charles Wood:

Yeah, I like that. I'm going to take it just a step further because it sounds like... I know in most of the places I've worked at, yeah, you've got those one-off things that you're just doing over and over again. Build a couple of them in

 

Ravi Parikh:

Yeah.

 

Charles Wood:

it. I mean,

 

Ravi Parikh:

Yeah.

 

Charles Wood:

you'll see whether or not it's a good fit. So

 

Ravi Parikh:

Right.

 

Charles Wood:

yeah, cool. Well, we'll go ahead and wrap up here. People want to sign up, just airplane.dev. Is that the best place to go?

 

Ravi Parikh:

Yeah, that's the best place to check it out. And if you want to get in touch with me for any reason, I'm just Ravi, R-A-V-I at airplane.dev. So, I would love

 

Charles Wood:

Okay,

 

Ravi Parikh:

to chat.

 

Charles Wood:

cool. All right, well we're gonna wrap it up here then. Airplane.dev, Ravi at airplane.dev. And yeah, till next time folks, Max out.