How do developers consider Airplane as a solution compared to developing a React app or purchasing off-the-shelf SaaS for their internal tools?

For the latter things like off-the-shelf SaaS, the vast majority of use cases that people use Airplane for, or at least the ones that come to us and use Airplane, there's usually no off-the-shelf SaaS that would just do it. 

No one's building a CRM in Airplane, for the most part. It's mostly bespoke things like, "I need to build this internal admin panel that does these really specific read and write operations against our production database." If you were using Django, maybe you could use Django Admin, or if you're using Rails, you could use Active Admin. But if you're not using one of those specific web frameworks, there's no off-the-shelf SaaS that just does that for you.

In terms of build versus buy essentially, that is the primary thing that people are usually evaluating with Airplane. It's not actually like Airplane versus Retool. Ninety percent of the time it's, "Either we're going to use Airplane for this or we're probably going to build this in-house." 

The way we navigate that is, Airplane is pretty different from most of the other products in this internal tooling space, in that we're not a low-code, no-code solution. Airplane is entirely a code-based product.

So, if you're saying, "I really want to have a lot of control over this and I want to use React to build the front-end," you can actually just do that in Airplane. We give you a component library, the state management system, and a bunch of built-ins that make it easy to build internal tools. But you’re still writing React code, at the end of the day, if you’re building a view on Airplane.

We like to think that using Airplane lets you have your cake and eat it, too. You can take advantage of all the niceties that Airplane gives you out of the box in terms of handling permissions and notifications etc. that will accelerate your time to development, while at the same time getting all source control benefits of code. Airplane's fully extensible. You can import your own private libraries or third-party libraries, so you don't have to make that trade-off.

When people look at Airplane versus in-house and still choose to go with in-house, there's usually one of two reasons. 

First is, they've already built it. They're like, "Well, we have this legacy system. We know we want to overhaul it. Airplane seems neat, but we don't really want to rebuild from scratch. We'll just incrementally build on this thing we've already done," which is fair and I think that's fine.

Second might be, there's something highly bespoke they want to do which is probably going to be more trouble than it's worth in Airplane. If the UI you want to build internally is really specific, and you're not going to take advantage of our component library at all, then, Airplane's not really giving you that much value. But that's really rare. There's some tables, charts, maps, graphs, some form fields, and buttons and they look the same. That's the Retool thesis as well. But occasionally, someone will have some really specific needs. That’s when I'll be like, "Yeah, maybe just build that in-house. That seems fine."