Kshitij: Hello, everyone. Welcome to another episode of the Tractable podcast. I'm Kshitij, co-founder and CTO at Orb. Today, I have the pleasure of speaking with Josh, who's the founder and CEO of Airplane. There's a lot going on in Airplane at the time that we're recording this. It's the company's first ever launch week.

We have a lot to chat about. To set the stage for what Airplane does, Airplane helps companies build automation and internal tools for operations, engineering, and support.

And of course, you all have an incredible set of customers, including companies like Copy.AI, Pave and Modern Treasury. So really excited to have you and welcome to the show. Thank you. I'm really excited to be here. Yeah. So maybe we can start with just a little bit of context on Airplane. Would love to hear about the product in your own words.

And then also how would you describe the vision for the company and the vision for the product, both in terms of what you do today, but also what that looks like in the long term?

Josh: Yeah. So maybe I'll do this chronologically. So Airplane, the name a bit of a, went the generic down approach as a company.

And are slowly working up the SEO ranks to be first there. It's by design generic. It did come from the small inside joke on being a lightweight control plane for your company. So there's this concept of a data plane and a control plane in a lot of systems. And we wanted to be the brains and the control center for operating the data plane of your company, so to speak.

And so that's where we started. And the original idea was like. Very simple, take a script, right? JavaScript, Python, whatever, deploy it to Airplane, and just run it from there instead. Because we saw across a lot of engineering teams, back at Benchling included, that pattern eventually caused, what caused started from someone running a script on their laptop and maybe taking it down prod and the team meeting for a retro and saying, hey, let's not do that, right?

Let's build a more responsible central place to deploy. And so we started really simple and my co founder and I just thought, why not? Let's see what happens. It seems like a mildly useful tool. As we built it, it became pretty clear to us that this would become like the compute piece, the lambda of a broader tooling platform.

So we thought of the first thing we built Airplane tasks as AWS Lambda, but also with SOC 2 features like auditing and fine grain permissions and also notifications and requests and approvals, right? All the things that our teams in previous lives just either took way too long to build or never built and just ended up in ultimately a terrible tool.

That's where we started, and over time we've evolved this, right? We now, I like to, I call Airplane a very full stack infrastructure company, because we have the core runtime of deploying, executing these tasks, but we also have Airplane Views, where you can build UIs on Airplane. And we also have the platform, right?

Which I mentioned earlier. And so longer term, I think of Airplane as the infrastructure layer for everything non prod at your company, right? So companies will sell products, they're going to buy products and they're going to build internal products. And so that third bucket of everything else is a lot of commoditized, undifferentiated work.

And so Airplane's i idea here is to suck all that up into one place, solve the boring parts for all of our customers, and just secretly be powering, as many companies as we can in the world. It's just what kind of superpowers do we want to get for our customers, right? This ability to execute a script from anywhere, this ability, these components to build UIs really quickly, it could be like notifications and approval flows.

And so, you know, AWS has hundreds of services for building out your infrastructure. I think Airplanes can have, maybe not hundreds, dozens and dozens of different building blocks and services you can connect together to build these sorts of internal tools, business software.

Kshitij: Yeah, that makes a lot of sense.

And one thing that you all talk a lot about both publicly and just in the way that you framed it as a full stack infrastructure platform is really this focus on the technical audience and the developers. So talk a little bit about how that fits into your vision, because, you could imagine internal tooling being built by folks who are not developers and maybe some companies take that thesis very directly.

So I'm curious for your insight on why the big focus on scripts Right. And people building with Airplane and building UI components rather than just piecing them together, so to speak.

Josh: Yeah. Yeah. And maybe just to get out of the way, I'm not anti no code, low code, right? I think the world's a big place and there's different people doing different things.

And there's just plenty of tools to serve different kinds of needs. But I think that there is a underserved perhaps segment where code is better. So for example, right? Like we found that a lot of large enterprise SaaS companies, you have these like delicate little, it's like that XKCD comic where there's one tool that's like upholding like the entire customer success team's operations.

Like back at Benchling we had a user onboarding tool and if that went down, meaning like, there was an error when you hit when you try to upload a CSV or something. And I had a few hundred scientists being onboarded the next day for a seven figure contract. That was a high severity incident, right?

Like we page people like you had to fix that ASAP because that was like the production line of the company being blocked. And so we see a bunch of those scenarios where you don't want a marketer dragging and dropping a SQL query that's querying from your production database. It's likely breaking a bunch of your security policies.

It's likely not going to resist any change control and so it's just an outage waiting to happen either on your prod DB itself or on the tool at the very least. And so the idea with Airplane is that there are at the end of the day, engineers building these tools, whether we'd like it or not. And so let's make their lives easier.

And so Airplane inherently targets larger scale, more critical situations, operationally intense places where, some companies are probably 80 percent internal tools, 20 percent product. And it's more of our focus, right? And so with Airplane, we started code first, we try to match developers to their workflows to where they are and so I would say it's like we're more matching developer workflows and just developers, right? Yeah, you can be technical and not, maybe that's not your day-to-day job but at the end like the idea of version control, code reviews, promotion through environments, rolling back right, grepping through your code like yeah, very basic stuff like that.

We take for granted using your own IDE, right? And so that is what we want to target because that is the core audience and the work flow that we care about.

Kshitij: And it sounds like a lot of what you're saying is that when you go to build something, an Airplane, that's going to be someone technical. That's going to be someone who wants, to work in their own IDE, have a great command line experience, have version control.

But presumably the folks who are using the Airplane task or who are running things in Airplane, that's still a pretty broad set of folks internally at the company. Is that right? Like it's not just that you're building the output of the workflow or the task is not just a technical audience, right?

Josh: Yeah. Yeah, exactly. So we call them builders versus operators, right? Right. So the nuance here is I think there's the core DNA of what Airplane is, which is we make builders' lives great and they create an app that makes operators' lives great. And on the operator side, we try to keep that UI as clean as possible, snap fast.

And there's a, a nice design system in there. And yeah. But over time, I think you do start blurring the lines, right? So these operators are typically on a support team, other engineering teams maybe outside of the core platform team or maybe they're like operations people, right?

We are moving towards enabling more of those folks to ad hoc build, quote unquote, on Airplane, but the difference is the core fundamentals of Airplane are virtual. So you don't have the risk of someone running an unapproved SQL query, right? And you could say, Hey, Josh, here's a generic way to reset a customer's account.

And maybe as an operator, Josh could then say, let me build a quick workflow that chains these three tasks together. We're not saying operators go away, like just do exactly what you're, assembled, but we said, we're saying the core building blocks here. Should have the level of rigor and in turn, we can now enable you as an operator to do more, more flexibly and just as securely.

Kshitij: How do you think about how opinionated you are in terms of the operator side of the story, right? So this kind of tension you're getting at, which is operators, may want some set of defaults that are good for them, but then developers might have different opinions about how to build those primitives or you know they might want to set up some super complicated thing that doesn't work for operators.

So you're almost having to like figure out the relationship internally between a developer and an operator. So how do you think about that tension?

Josh: Yeah, it's a great question. It is hard because, a lot of times when we've been opinionated, it's gone dramatically one way or the other, right? Like some cases of being opinionated on hey, everything's just a form. It's great because turns out a lot of things are just forms and you know you'd expect people to want to really customize things but most people don't and that's that was a great path.

On the other hand saying things like, oh everyone has a certain kind of permission structure and we should just build that in or notifications, build that in, you end up getting a bunch of requests for different configurability. I want this thing to notify only if it's after it's failed four times and you're like, oh man, okay, we were very opinionated to start and we'd loosened that over time.

So I would say we're at the end of the day there's the more obvious pieces are the places that aren't specific to a customer's workflow. Certain things that are just check the box or certain things like UI pieces where just given our awareness of the domain, right? We know that it's largely the same across everyone other times I think it is just we like to say that like the complexity of the solution should match the complexity of the problem you're solving. And so if I want something really basic that should be opinionated and easy to use. I shouldn't have to figure out all these libraries if I just want a damn form with a damn chart right on my page. But if I'm like all of a sudden I want like sophisticated caching rules and I want to show this other chart based on this other selection state and only with certain permissions, right?

If it's more complicated, maybe the work that needs to go into it should be harder. And then the nice thing about being developer focused about SDKs is that code actually allows for this sort of progressive. functionality, right? Your basic examples, you have reasonable defaults and then you let people take the, like you provide molecules and you let people take the atoms as necessary, right?

So that's the approach we take for places where it's developers controlling it. And then I can't say we've properly solved for like the platform challenges where you don't get the developer, like the notification thing, right? That's double pain for us because people have different roles and it's okay, like how do you target the common denominator?

How do you log configuration without 30 different fields here? And I'm just like, yeah, that's ultimately just like why you hire great designers and product. Yeah.

Kshitij: And I guess speaking of things like configuration and being opinionated, one opinion that. Lots of products they have in the market is they're going to be SaaS only, right?

Like you have to send all the data to them. And that makes oftentimes for a simpler architecture, maybe it makes it easier to iterate on the product, maybe even affects the security model in significant ways. So one thing I'm wondering is. I know Airplane is pretty unique in this way.

So can you speak a bit to the components of Airplane's architecture? How do you all deploy Airplane? And what does that look like in terms of your development lifecycle?

Josh: Yeah, for sure. So I like to, say we're almost like an inverse Cloudflare, where Cloudflare, other sort of CDNs, and Edge Networks try to be as close to the users as possible.

We solve problems by being as close to our customers, VPCs or data centers, right? And so we're really good at running all these distributed clusters of agents across all of our customers, right? All of our largest customers operate with our agent, we call it within their own VPC. So we give them a Terraform stack or a CloudFormation stack or a Helm chart, and they're able to launch this agent, which then takes instructions from our control plane and figures out the scaling, descaling networking kind of decision that needs to make to run your tasks.

And so our customer gets this like self hosted serverless platform with like very little maintenance and honestly, I think it's like under appreciated. But maybe that speaks to where we've moved as an industry, right? It's oh, great, it's like a serverless platform. Of course. so we solve this core runtime problem of allowing these tasks to execute within everyone's network.

And so it's a bit of a hybrid model, right? You can call it on prem in some regard because the compute and the storage now are all within their networks. What happens is if you're a user and you visit the Airplane site, we actually are able to route based on the data you're looking at. We route the browser to the right load balancer and essentially a gateway to get to that data.

And there's a bit of authorization and so we do there, but at the end of the day, it means that Airplane for our self hosted customers doesn't actually ever see the data that they're working with. And so far we've been able to do that with like very little, but still keep the main core parts, right?

Permissioning and API access the build process on our platform.

Kshitij: How do you think about, something like observability in that model, right? So I'll give you a simple example. Let's say I'm deploying Airplane and I'm deploying it on Fargate and, I hit my AWS quota limit on number of tasks I can deploy.

And now something is failing to come up and I can't run my task and you know, it's not Airplanes fault per se, but it is something where presumably you want to indicate that in your product to your to the end user saying, hey, something's going wrong with running this task and this is something that you should look into.

But now you're transferring that burden of figure out what's wrong here yourself. So do you face that a lot or do you feel like you've been able to get that observability in, in enough ways just from the control plane side?

Josh: Yeah, that's a good question. I would say it's definitely a challenge.

I think we've gotten a lot better at it. One thing that makes this easier is that, whether we like it or not, there's really only two target compiler targets, so to speak, for the cloud and that's either AWS's APIs or Kubernetes APIs, right? And so that's what we support today. And so a lot of the learnings we can encode back into the templates we provide.

So for certain Fargate things, it's like the memory configurations we use, it's the pre warming we do. So just knowing that this tends to be a problem. We can sometimes we can solve it from our side. The second layer there is around like metrics and observability. And so we actually have our own internal open telemetry endpoint that our agents if opted in, can send that anonymized data back to, right?

So things like just metrics runs numbers and things like that. And so we use that for our support tooling, but also what we would love to do the next like few quarters is have a dashboard with an Airplane, right? That can just show you here's the health of your agents and the task executions and everything.

Yeah, we also do export that to data doc and other open telemetry. And so we can let you bring that into your own systems and observe that. Now there is that third bucket though, where it is like the user's fault, but ultimately Airplane, the Airplane experience is affected, right? We had someone change a VPC route table rule that essentially cut off all their agents.

And then they filed a sub zero incident with us because the Airplane is down. And so at the end of the day, like it's still whether we like it or not, that's how we need to reduce how often that happens. And so that is a real issue, right? I think at the end of the day, it's simplifying it as much as possible is like the only way we'd solve that.

For our larger customers, we do start off saying, hey, Fargate limits. You should look into those. Cause yeah, we get that. But, a lot of us, we try to keep it simple. It's Fargate, very serverless, very few moving pieces, right? Very femoral containers, very little state that can go wrong.

The number one thing that I, push on the team is like, the number one risk in all of this is state. Anywhere you have state is a potential problem. If your entire thing is stateless, you have like very few problems comparatively. Even our storage piece, it's like we use S3 or whatever storage object store.

It's all immutable. So it's a very simple state system and that definitely helps a ton. So if you mess up, you want to redo your agent setup, which is you can do everything except for the storage, right? And recreate it. That's a important property for us to maintain.

Kshitij: And my understanding is not everyone is on this sort of cloud prem architecture, right?

There are some folks where you actually do host the execution and it's not running in a Fargate task, let's say, in their environment. Has that been, have you had to add a lot of branching between those two models or has it been a useful constraint where you know, a lot of the, a lot of the execution environment and maybe like you're saying that the stateless way that you execute tasks has carried over across those two things.

Josh: It's a great question. I think it has gone in the way because we are running Kubernetes for our own and we need to support ECS Fargate for some customers. And so that's the biggest one. We're in the development flow. It's okay, let's go add kube support. Now, let's add ECS support.

And so we have, two or three different drivers we have and we just have to implement, it's a classic interface. You know, like Implement it for each one. So that's largely been okay because we've like defined it as like a driver that we just install in. But we do try to run our own cluster as like an untrusted agent, right?

So we have a multi tenant flag we turn on that turns off certain pieces of that a customer has obviously different scaling rules the Kubernetes cluster and different limits, but we try to keep it as close to if you're running Kubernetes in your own network as possible. And so when customers ask what can this scale to in my own VPC?

And we're like we handle probably 1000X, 10000X where you're running on a day-to-day basis. So we definitely think you can scale to this amount. So we try, we do try to keep it as similar as possible.

Kshitij: And does that mean it's pretty seamless if people want to, I don't even know if this is common, but moving across models, like oh, I want to bring this workload into my own VPC.

Is that something, is that a migration you talk through a lot?

Josh: Yeah. We don't talk through a lot because it's so easy, right? Like we have the opposite problem where it's potentially confusing. It's like, you still go to app.airplane.dev. You still do all your, nothing changes. All right.

Because each run is immutable and like different layers on top of the pre like ignores, is independent of the previous one. And so you hook up your new agents, you turn off the Airplane agents and all of a sudden the execution is now being routed to a different region, AKA your own DPC. So it's very transparent to the end user.

And yeah, so that happens a bunch for people who try it out. Mess around with the test database and then, okay, now it's time to connect to a real database. Let's set up the agents and let's reroute that.

Kshitij: Yeah. One thing that I've noticed in your developer docs is you all put a lot of emphasis, not surprisingly so on developer experience. You have some pretty rich guides on how to run Airplane locally pretty well developed CLI. How do you think about that developer experience? Is it like you were saying, a few core principles of keep things stateless, make sure that you can get started very quickly, keep that the complicated details abstracted away from the developer as much as possible.

Are there other things you would include in that list as driving principles?

Josh: Yeah, that's a good question. I think the core one is really more meta. It's that people like to think that there's like a silver bullet here. It's just you have to care. Like your founders have to care. Your eng managers have to care.

People have to if, someone on the support side says, hey, these docs are confusing. That feedback needs to be taken in and you need to improve it. And that's all it takes, so to speak, at a high level, because everything else flows from that. But yeah, we do have some core principles. I think, one, I've come to have a pretty strong, let's call it like either a pet peeve or opinion on like how a doc should be structured.

It's it should be, here's the high level, here's how to get started to illustrate what the feature does. And if you need all the details, here's like a great thorough reference. And the issues we've seen in our docs is when we like try to blend that and you go too deep into the reference at start, you have too many examples or you don't really describe what the thing overall does.

So there's this like one, two, three of what does it do? Show me it. And okay, I know what it does, but I want all the gory details. Let me like put that in a separate section. And so I think that really like lets you do a progressive sort of enhancement on a user's knowledge, right? Is it fast?

And when things go wrong, are the errors clear? if you can handle, the happy path well, and then handle the unhappy path well. So those are the three, right? Are you documenting this? Is it speedy and do you handle the errors?

How do you handle errors? And I think that it's, a lot harder to go wrong when you cover those.

Kshitij: Yeah one thing you said there about docs hierarchy, I think about this in the context of increasing product surface area as well. So as I was saying at the beginning, you're in the middle of this launch week.

And so I'm curious, how have the use cases or maybe even the like technical implementations of Airplane changed as the product has expanded. Is it that, there's developers are really looking for a specific thing in the docs. And, now that you have five things or 10 things, it just gets, it gets buried or harder to find.

So both in the context of how you think about developer experience, but also just how you think about the product as a whole. And as it evolves, what is increasing product service area done?

Josh: Yeah. It's tough, right? And I think if you ask anyone on my team, that's they're gonna tell you that. It's it is challenging to build a broad product.

So I will say, tactically, right now, there's two key things that I care about. One day zero, frankly people are starting with tasks, right? They're not starting with views. They're not starting with self hosted tasks. It's the bread and butter of what we do. So we better make that good.

And, I think there's like doc stuff that we do need to improve on. I think that is probably the strategic initial focus. Two would be people who are evaluating Airplane, but more from a sense of authority and security. Do the Airplane folks know what they're doing?

Do I want to trust them with like my internal tooling? And so that is where like things around the platform and agents and security does. These things do matter. And so that actually is too, it's like a sales, essentially sales collateral, right? On this is why Airplane is a mature company that you should, that you can build good stuff on.

And those are the two goals, quote unquote, right now for the docs to start. And I think everyone needs to start from there, right? You really had to come back from a product requirements perspective of what the doc product should do. I do think that you need to basically identify the common patterns of what and really optimize for those.

And you end up segmenting it so that. I should be able to understand views with minimal understanding of tasks, or, you make clear what, okay, before you go into views, you should understand A, B, and C, right? Or if you're doing Airplane postgres stuff, you basically want to reduce as many of the dependencies as possible, I think to keep it to be a tractable problem.

The extreme of this, you see something like AWS, right? Like none of the teams know about each other and like the duplication and it's sort of a problem. But like, you know, maybe it's a hot take. It's sort of not. It's sort of good, right? It's like the only way you can scale that way. And so I think that's a longer term perspective.

Kshitij: Yeah, I think that makes a lot of sense. And I resonate with that. I think one of the tricky parts of building docs for a product like Orb is the workloads are very different. So for example, some people want to send us hundreds of thousands of events a second, and some people want to send us 10 events a day.

And so it's great. You can, if you think of docs as a sort of marketing collateral material, you really want to focus on scalability, but a given set of developers, that's the information is not that relevant to them and they want to skip over that. So it's like tricky to figure out how do you tune the docs to really match both people in the weeds evaluating and people just trying to suss out things like credibility and does this product actually handle the scale that I have?

Josh: That's a good point. And I think that reminds you of there's a common pattern, right? Having your documentation, your reference. And so what you do is if you're new to this or you want to be handheld, here's like all the things you should read first.

Start here. But then you assume that, especially for developers, right? There's a common term, like the impatient developer . You assume that they're like, okay, I get it, Josh I just want, I really just care about this one thing. So you better have good search, you better have a good reference, right?

You better have good information architecture and let them like, find those things. So to the other point, there are specific things that people want to do. Like I want approval flow, or I want to integrate with this secrets manager. And so we should, we have individual docs on that. Basically it's like the, are you doing a scan or a random access? And so we put all this in the random access part of our docs.

Kshitij: Yeah. Yeah. One of the things I wanted to ask you is, you're working on kind of a storage product. You have to work across all these environments. What's the hardest technical problem that you would say you're working on. And maybe what would your team say is the hardest technical problem at Airplane?

Josh: Yeah, I would break it into two pieces. One, the most if you just look at very pure technical challenges in the maybe like programming interview sense, I would say it's definitely closer to like our runtime layer.

How do you build across heterogeneous set of environments? You do take advantage of the idea of an Airplane task being a simplified concept, right? But how do you take that and, we have a project coming up where it looks like we have the equivalent of a cold start, warm start of our task.

How do you reduce that by a factor of 10? How do you make that 90 percent faster? And, those things are it's very challenging, but very fun on figuring out how you get workloads, how you can just optimize like image pull times, how you can schedule things efficiently. We did one optimization where like the way we build things is we share a lot of the image, we share the images between the certain tasks that are deployed together.

And so it dramatically improves the caching and reusability of these tasks and really brings down the build times there, right? So it's a very fun combination of taking shortcuts, you can take knowing that there's certain product limitations that we can work with, but then also trying to solve that across all customers and just make that faster, take a number and make it lower.

And so a lot of engineers love to do, but on the larger scale, I think it's really a more of an architecture problem we're trying to solve here. How do you build such a broad platform without going crazy? I think you do need better services or interfaces or whatever the domain is. I think you saw this with AWS, for example, right?

They're very famously service oriented and for us, it's less you can't just speak in microservices, but if we're building a component library, some of the painful learnings we've had is, like, how do you make that reusable across? Different context right across the view versus the app versus this new thing we're building called pages, right?

How do you share that design system and props? system everywhere and so everything ends up becoming an architecture problem, right? Where do you draw the boundary? What is the responsibility of this submodule? Can I then have another team working on another submodule as quickly as they can without slowing them down by this other team's work?

The studio is another example of this right? It's a big challenge for us that we're honestly still working on How do I rapidly build new products without being hamstrung by adding studio support for everything, allowing editing support of everything? Can I like not have to reinvent that every time?

And so it's a architecture problem. Everyone has to think about it.

Kshitij: Yeah. And I think there's presumably some parts of Airplane that are hard to draw clean boundaries around. So I know you all fairly recently introduced a AI focused product, right? And so I guess I have two questions there. One is architecturally, how does that fit in to these other sub modules, but also as a product or business level obviously LLMs are really hot.

They've been popular for about a year and a half now. Do you feel like that's a kind of pivot to the core thesis of Airplane or do you think that's purely additive?

Josh: Yeah, that's really interesting. So the architecture piece is interesting because so far the easy way to start with an LLM is to think of it as a human that is miniaturized put into your browser or computer and it's always available for you to talk to and so in that model so far, right?

We've actually not changed a lot of things for this. So for example, right? It indexes all our and it's a good reason why you should have good docs. We found out that some of our docs weren't really great at not just humans, but also LLMs, and so we clarified a lot of our documentation. We tried tagging a lot of it better with this is our Python docs, this is our JavaScript, and so based on the language, our LLM could figure out the right things, but these are all just done external to the core documentation, similarly in the studio, right?

We have these like studio hooks where there's like a shop script functions you can call to manipulate files, to open a tab, right? So we built like a bit of a mini API to the studio and then autopilot, which is our assistant for helping you build in the studio, just makes calls to those. It's still very much let's just assume there's a human doing this.

What's the API you would give them? And now, okay, it turns out now it's a AI calling that.

But yeah, it's been a fun architecture problem trying to build for this. Now I would say in terms of, is it a pivot or not? I definitely don't think it's a pivot. The question is like, where and how do you want to play apply AI?

And I frankly think a lot of companies like we took a bunch of just really smart and fast learning engineers and built an AI product in three to four months. And so I, if we could do it, I bet a lot of other folks can do it. And so I don't think Airplane just because of this is like an AI company.

Now, a lot of companies will adopt AI and we'll use it. And that's great. As like a threat to our business or a boon to our business, I think of it as there is build time and runtime for Airplane and autopilot so far is accelerating build time. And that's been interesting. One, our users get it really quickly because they get to the same destination, but faster.

And luckily, they've all been using chat, ChatGPT for a long time now. And so the ease of adoption is a lot better. The utility is lower though, right? Cause you're not like to use this it's like taking a little effort from a hundred units to maybe Airplane without AI takes it to 10 units.

Right. Which is like, oh, this is great. I love Airplane. I'm going to use it. But then AI maybe takes it from 10 units to two units. And so from 10 to two, it's massive from a hundred to two versus a hundred to 10. Either way, if I cross my threshold of being great. And so I don't think it's like necessarily an inflection point for everything it is, but it is like the new way that things are built.

Right, and at runtime is where I think it gets more interesting. There's a lot more unknown still. What I mean is that once you've built something can AI help you stitch things together? Can AI suggest the right things to do? Can AI say, hey, you're about to like, typo this email hold on a second.

And so I think that is where it gets really interesting, because now it's not just getting to the same place faster, it's a new destination of where you are. And so I think my answer around the architecture piece like that will look different for that. But we haven't really explored that fully yet.

Kshitij: And maybe to take that to a previous framing we were talking about, would you say that, autopilot or AI in Airplane is really for the developer today? And then in the future, you're thinking, how does it work for the operator, right? Like separating out those.

Josh: Exactly. We call it like autopilot for developers or autopilot for operators, right?

So that's exactly how we think about it. And I think the question of does this pose an existential threat to Airplane, right? Because I think that's a very valid question that I'm still thinking through and like right now I think that AI is going to be really good at combining pieces together. But like it's still yet and not as good at like just creating a table component or creating the runtime that you're executing and so we jokingly say let's just build all the building blocks for our like AI supervisors that are coming in the future.

Internally, we have an assembly team. That's like how things come together and a capabilities team, right? We're just building the capabilities for an AI to sit together. So I actually think it's going to be really good for Airplane because our value is twofold. And so with AI you get the same building blocks Airplane provides, but you combine them a lot faster.

And so it doesn't replace Airplane, it just makes Airplane a lot easier to use. Obviously, I'm biased in this maybe speaking my book, but , yeah, that's how I see it.

Kshitij: I think architecturally one unique thing about AI is oftentimes, at least for a lot of companies, it has real COGS to operate, right?

Like you're... presumably calling out to maybe it's just some like vector database. Sometimes it's, just another generative AI company that's powering the model. How do you think about that from a, again, architecture and business perspective? So from the perspective of pricing on the business side and from the perspective of maybe even things like performance and latency and all the stuff that comes with, potentially third-party reliance.

Josh: Yeah. I'm not worried about performance just because I think it's going to get a lot better. I don't think we're anywhere near the scaling, like limits that, maybe we saw with CPU. So I may, very high level gut feeling, but I think it's one of those things you just wait a few months and it's going to get faster, right?

So I am worried about cost in that - yeah - like at some point we're experimenting with GPT 432k for everything and we're racking like every message you sent would cost us like half a dollar, right? Cause we were sending everything to this prompt every time. And so yeah, there are dumb, there are ways where we can be dumb about it and burn a lot of money, within balance, reasonable optimization, right? Like we have this two-tiered thing. We set it to GPT 3. 5 first, which then feeds it to GPT 4 only if we need to write certain amounts of code. And so by doing that, the costs are pretty reasonable. And once it's within that regime for enterprise SaaS, especially for where we choose to apply AI, as long as we tie it to value and, with something like Orb, as long as we can bill for usage of that.

So my goal is to just run at a cost. And so if it costs us a few pennies for this, like maybe the model is you get a certain amount of like requests per month built in, let's call that customer acquisition cost and the rest of that there's a billing model for the number of responses.

And as long as we can average that out to how much that costs us that's fine, right? Cause I don't need to make money off of this. I just need people to use Airplane more and then we'll make money off our course queue, which is the number of seats you have on Airplane.

Kshitij: Yeah. So it's almost like a way to accelerate the onboarding or accelerate the utilization of Airplane more so than the kind of core business drivers, especially if you're thinking of running it at cost or billing it at cost.

Josh: Yeah, exactly.

Kshitij: And one thing people worry about a lot with these AI products, and I'm sure you've probably heard this from a bunch of enterprises is privacy, right? And so not only privacy in the context of AI, but for Airplane, I'm imagining that's a hot topic whenever you're selling to, to especially big companies, because they're very sensitive about internal tooling.

And I'm imagining internal tooling has access to a lot of their customer data. Is that something where you have to navigate that on a deal-by-deal basis and think about their concerns or how have you figured out a way to talk through that motion and is it just like architecting for it?

Is it a really strong talk track around it? Is it? Is it just something completely different?

Josh: Yeah, that's a good question. So first, I think of scope, at least for ordering right now, which is that we're not setting your database contents over at build time, we are luckily working with your code, maybe your database schema.

And so at least it's not our customers' data, right? It's our customers' IP, their code. And so it is one step less sensitive. We will hit more serious issues when it's autopilot for operators, for sure. I think at the end of it, there's a lot of noise around security because my take is that the core of it is about trust It's not about regulation, it's not about specific laws.

It's about do I trust ultimately OpenAI or Anthropic because everyone trusts AWS and GCP. You already are sending your data to one of the clouds, obviously it's like three of the largest businesses in the world, like they deserve that trust. And the question is, does OpenAI deserve that?

It's not a technical issue. It's whether or not that's SOC 2 and that terms of service about not trading on the data, whether that holds water or not. And so for a lot of customers, I think that does, right? It's the same way you trust a lot of your vendors right now.

Airplane has a few select subset of subprocessors and OpenAI being one of them is not really that different. Now, there are customers where like by policy or by lack of trust, they're like, we can't use some AI. The pattern I have seen luckily LLMs have invented like the simplest interface we've ever seen, like it's like natural language, right?

And I think that, there's a pattern that I've seen a lot now where you can bring your own model. And so there are challenges with the nuances of different models, but at the end of the day, as long as it's like a co-generating model, you can probably go into the interface and say send it to here instead.

And so I do think that is likely an approach we go for the larger enterprises, right? There's the third option, which like everyone's okay with Azure OpenAI, and so that is also like you're looking for hacks, right? That's option three. Same exact API, you just say it's Azure OpenAPI and it gets a different set of expectations put around it.

Yeah. I would try that first.

Kshitij: That's interesting because I think that really does point to it being a, you already trust Azure. You're maybe already sending your data to them and despite nothing being different, it's like the organization handling the data is different. Yeah.

That's what matters.

Josh: Yeah. Don't get me wrong, I'm not belittling folks for doing that. I think it's like a very valid way to think about it. We're so glad you got to experience this. My concern is when it's brought under a technical issue, whereas it's more of a organizational and trust issue, right? And just to expand on the Azure OpenAI thing, there's also Amazon Bedrock, right, Google Vertex, and I think they all have various variants of these models. And I actually think that's a very... maybe not option three, but option two, right?

Kshitij: Yeah, that makes sense. And I guess maybe last thing to wrap up. We've talked about a lot of different things happening. Airplane, I want to give you a chance to talk a little bit about what's happening at launch week.

And then maybe zooming out. What are you most excited for in the coming quarters that Airplane is building?

Yeah, this is our first ever launch week. And so it's our baby launch week. We're really just trying to build that muscle and celebrate and talk about our wins a lot.

Because we ship a lot and as engineers we tend to just move on to the next thing. We have a roadmap, we got to execute on it. And so it is just saying, hey folks, let's like get into this cadence quarterly to, maybe we're not going to affect how fast we develop things based off it, but we are going to make louder noise once in a quarter and try to group it up together.

And so, also there's not a clean theme to this launch week other than just building. What are customers have really asked us for right? So day one has been Airplane pages, which is our new umbrella where views and other UI buildings going to go under. Turns out not a lot of the world likes writing React, even though a lot of the other customers we talked to did. And so we're building ways so you can just declare a UI.

Josh: Because a lot of internal UIs are really simple, right? A table here, a chart here, and a form here. And so we want to make that simple stuff simple to build. Day two is Airplane Postgres, right? We're partnering with the great folks over at Neon to enable you to bring, click a date, click a button, and just get a database in Airplane.

Yeah. Day three has been Cloud Workspaces where, you know, as much of our power users love CLIs and local workflows and get if you're just getting started, if you're eval-ing Airplane or demoing, you don't want to go through all that. And so we want to make that really easy. Just start building stuff with seconds of setup instead of, I don't know, a few minutes.

Yeah. Day four, coming soon it's going to be more around our enterprise work, working with larger orgs. We've really been put through the strain the strainer whatever the term is on, the various storage requirements, or audio requirements, and so, it's been great pressure to make us build a more enterprise grade product.

And so, day five is a wrap up, so there's not much there. But, these are the sort of things we've been building, and we really wanted to share with the world. Now, what I'm excited about coming up is building, what we can build on top of this. And so there's two themes that I've been really thinking about.

One is around just like Airplane as a control center. It's one of those things that like you really only start seeing now that we're selling to like larger enterprises. But it's one of those like people like to eye roll and find it boring, but I honestly find it very exciting where there's if you can get better visibility, search ability of what's happening in Airplane, right?

All your team's sensitive operations are now in one place. And so we can really give you value on top of that. The second angle is around Airplane as an operating system. And this is like Airplane autopilot for operators, but even just non AI, good old traditional, building a good product around it, right?

We've been focusing a lot on builders for the last like year, two years. I think we need to give operators more love. So how do you say, how do you build experiences? Like, "Welcome back, Josh.". the last thing you were looking at was this list of users. Here's like that view brought up. And wait you're looking at suspicious user, you search for some fraud.

Here's a task pre filled with that user's information to suspend them. Right? Or like, here's a notification. How do you act on it? All these things are already there in Airplane, right? We just have to like know how to surface and connect them together. And so I'm really excited about that because you can only get there with the foundation that we've built so far.

Yeah. Control center, operating system maybe two halves of the same coin. But , I'm really excited about the stuff we can do once the basic primitives are in.

Kshitij: Awesome. That sounds very exciting. And I'm personally excited about that. We're happy customers of Airplane over at Orb. Looking forward to it.

And thank you for taking the time today. It was great having you.

Josh: Thank you. It's always fun to uh, ramble about these things.

Awesome. Thanks, Josh.