Airplane: A New Approach to Internal Tools

Airplane: A New Approach to Internal Tools

Jul 23, 2021
Ravi Parikh, Founder at

Today we're publicly launching Airplane, a platform that lets engineers quickly create lightweight internal apps for their teammates. We've been in closed beta for the last 6 months, but as of today, Airplane is open for anyone to sign up and try out.

Why existing approaches to internal tools fall short

My co-founder Josh and I both spent the last 7+ years at two different SaaS companies.  I previously co-founded Heap, an analytics company, and Josh was CTO at Benchling, a research informatics platform. In both cases, we had large customer-facing teams–support, professional services, sales, customer success–who needed to frequently read and write data on behalf of our customers. Both of us were frustrated with the state of internal tooling at our companies, and after leaving, we also spent significant time talking to folks at several other companies to get a sense of how others built internal tools.

We found that there were tons of approaches, but the same core problems kept coming up over and over again:

  • Accessibility: Many key internal operations are inaccessible to the people who needed them. A customer success person needs to update a customer's payment plan, but only the CTO has access to the Stripe console. An implementation specialist needs to bulk import data into a customer's account, but they need to ping an engineer to kick off an airflow job. The work it would take for engineers to make these operations more accessible is massive–UIs, input validation, permissions, auth, etc.
  • Safety & Trade-offs: Companies are faced with a trade-off between safety and accessibility. Early-stage startups might opt for an approach where everyone is executing write queries against a prod DB to update customer data, running poorly-tested scripts to fix issues, and other easy but unsafe practices. More mature companies tend to lock down access and err on the side of safety. But building the right access controls, audit logs, approval flows, etc to allow the best of both worlds–maximal access in a safe way–is a huge undertaking.
  • Time-consuming: Internal systems are often a product of not wanting to spend significant engineering time on them, but paradoxically, this leads to a lot of wasted time in the long-term. At Heap, we built a Slack bot that was seen as a "quick and easy" solution to internal tools, but it ended up requiring significant maintenance and had frequent downtime. We also had tons of one-off scripts that encapsulated key operations. These were initially quick to write, but led to engineers being interrupted constantly every time customer teams needed to run those operations.

The root cause of all of these problems at both companies was return on investment. To do anything non-trivial, internal tools require significant engineering time, but the perceived value to the company is lower than building another customer-facing product feature, so internal tools are consistently de-prioritized. They tend to exist at the level of, "what's the absolute minimum we can get away with here?" Engineering teams rely on ad-hoc scripts and SQL queries since building the right long-term solutions never seems worth it.

How Airplane is different

We built Airplane to address these problems. We optimized for a few criteria:

  • Speed: It should be possible to take any internal operation–no matter how complex or bespoke–and turn it into an accessible, reusable, safe internal app in minutes or less.
  • Flexibility: You shouldn't be forced to turn everything into a REST endpoint just so your tooling framework can work with it. It should be possible to implement the backend logic however works best for that operation–a command-line script, SQL query, application endpoint, third-party API, and more.
  • Safety: You shouldn't have to trade off safety against accessibility. It should be possible to easily specify exactly who has access to an operation, what constraints the operation should run under, make sure inputs are validated, make sure there's an audit log, and more.
  • Automation: Unlike other internal tooling platforms, Airplane automates a lot more than just the UI. We provide notifications, permissions, audit logs, multi-step workflows, multi-person approval flows, and more in just a few seconds of configuration work.

These optimizations don't exist in a vacuum. Every framework has tradeoffs, and here were the ones we chose to make:

  • Engineering required: Airplane is not a no-code, drag-and-drop tool. To use our platform, you need to be able to write code.
  • Limited customization: We don't give you a sandbox in which you can build whatever you want. Instead, providing strong defaults out-of-the-box for things like UI and notifications covers the vast majority of internal tooling cases and speeds up the process.

So how does it work? Here's a video showing an example of how Airplane can turn a JS script into an app with a UI, notifications, permissions, validation rules, and more in just a couple minutes of work:

What's next

Airplane today is simple–in minutes, an engineer can transform a script, SQL query, or REST endpoint into a lightweight app. However, this model will become the foundation for an internal tooling platform that can support significant complexity. Here are just a few of the things we have planned:

  • Runbooks: Every task in Airplane represents a single atomic operation. Soon, you'll be able to combine multiple tasks together into a multi-step reusable runbook that supports passing inputs from one task to another, incorporates human-in-the-loop decisionmaking, and more. This is already in beta today, so if you're interested in checking it out, let us know at
  • Out-of-the-box functions: The most interesting tasks in Airplane are the bespoke, company-specific ones you'll build yourself, but there are tons of operations that are common across companies. For example, issuing a payment refund is pretty similar in every company that uses Stripe. We're building a library of out-of-the-box functions that become especially powerful when combined with your custom Airplane tasks within Runbooks.
  • Integrations: Airplane will integrate with the systems your company already uses to get work done. Today, you can run any task directly from Slack and get notified there as well about the status of task runs. Eventually, we'll support things like making sure approvals go through your ticketing system of choice or invoking tasks from a Zendesk sidebar.

Our goal is for Airplane to be a home for all of your company's internal operations, while retaining the simplicity and ease of use that set us apart from other approaches.

Try it out today

Today, our early customers are using Airplane to quickly build internal tools for things like user account administration, customer onboarding, support, and more. If you're interested in trying out Airplane, you can sign up for a free account here. Feel free to reach out to us at as well if you'd like to chat and get a more in-depth demo.

We also have a lot of exciting product releases planned for the coming year–if you'd like to stay in the loop, you can subscribe to updates below.

Share this article:

Subscribe to new blog posts from Airplane:

What is runbook automation? A quick guide

What is runbook automation? A quick guide

Jan 20, 2022
Madhura Kumar
When you take a step back from the buzz of activities we generalize as work, you'll notice event patterns—repetitive processes. We can document most of these events and processes into easy-to-run steps in runbooks. Runbooks help make sure tasks are performed at the same level of accuracy and yield predictable and desired results. While runbooks tend to live in Google Docs or wiki pages, runbook automation is the process of using software to execute these more reliably, quickly, and autonomously
Why “let the support team build their own tools” rarely works

Why “let the support team build their own tools” rarely works

Oct 22, 2021
Ravi Parikh
Engineering teams tend to prioritize customer-facing features over internal tools. As a result, the state of internal tools in most companies–especially fast-growing startups–lags far behind where it would be in an ideal world. But there's a solution: why not just let the support or ops team build their own tools? There's tons of no-code vendors out there that promise exactly this. However, unless approached correctly, this won't work. Before diving in, I want to clarify that the primary reaso
go to home