Airplane is a platform for engineers to quickly build internal tools that power recurring workflows within their organization. Our mission is to streamline internal workflows that support, operations, engineering, customer success, sales, and other teams need to do on a recurring basis.
Customer case studies
The Delta uses Airplane schedules for a number of use cases including updating candidate statuses, removing unlinked client data, and generating a monthly static code quality report.
Panther started using Airplane to automate some of the more manual tasks that customer-facing teams like sales and customer success would ping developers on. It created a consistent, reliable experience that saves time across entire company.
works at Airplane
How are the teams structured?
We have short-lived pods that folks are split into. We have three pods working
on three main major projects that we’re going through, but they will restructure
every few months or so as priorities shift, so these aren’t long-lasting teams.
We don’t structure teams around product features or technologies. What kind of
product you get depends on the shape of your team. Everyone here at Airplane
currently is more of a generalist. There are different focuses around front end
versus back end, but the teams are structured around products that we’re
building. So, the mission of people on each team is to ultimately deliver a high
quality product and not just, say, a set of API endpoints.
We focus more on hiring people in US time zones, just so that there’s at least
five hours to work synchronously with other people. There’s a lot of small
things where it’s just easier to hop on a Zoom call and have higher-bandwidth
interaction. We lean on synchronous communication.
What tools do engineers use?
Communication: Slack, Zoom
Wiki and docs: Slab
Project planning: Linear, Productboard, Airtable
Support operations: Airplane
Infrastructure: GCP running Kubernetes
Monitoring & error reporting: Datadog and PagerDuty
Workflow management: GitHub Actions
Can developers pick their own tools?
Yes and no. If it’s going to affect the team, then we are definitely not a “let
a million languages fly” kind of company. There’s a bit of coordination that we
want to do as a team. The goal for the code is to be as anonymous as possible.
You should not be able to tell who wrote these lines of code.
When it comes to things that are team-wide we try to reduce how many tools we
have. But if it’s for individual productivity, if you have some way of working
about it that benefits you, then definitely. People are welcome to expense and
adopt their own tools. A lot of us are on macOS, but we have a few folks on
Linux. We have a bunch of Vim users, some using VSCode. I don’t know if anyone’s
actually using Emacs at Airplane right now!
How does the development process work? What’s the process for working through bugs, features and tech debt?
It’s an age-old challenge, and we don’t think we’ve solved it - it’s constant
prioritization. Most recently, we’ve switched to a one-week sprint, where we’re
optimizing for velocity over predictability. Each sprint is really just a very
quick retro, plus pulling whatever’s most important, then getting back to
building. Rather than, “Hey, I’m going to spend all Friday planning for this
two-week sprint coming up.”
The goal is to move a lot more quickly, and be more iterative. Everyone should
have a bug or a tech debt item for that week, just to make sure we’re covering
everything. The focus of the company also shifts regularly.
How does code get reviewed, merged, and deployed?
Every bit of code is reviewed. Approximately 25% of PRs have two reviewers. This
is an especially helpful pattern for handing off context or splitting up the
We use GitHub and GitHub Actions to handle the standard run, unit tests,
security scans and merging when it passes. We have a release train where we
automatically deploy the staging, and then the devs have about 30 minutes to
verify things, before it’s automatically promoted to prod.
We’re trying to balance this. We’re not quite ready yet to just deploy directly
to prod, but the idea is that if you merge something, you’re watching it go out
and if it’s causing issues, you should cancel the prod deployment. So that helps
us deploy often.
What is the QA process?
It is pretty standard, like a pyramid of testing, where most issues should be
caught by unit tests, or end-to-end tests. And then we have a few live tests,
like Datadog synthetic checks, that will make sure key features still work,
basic onboarding, etc.
Even manual checks; we think they’re not a substitute for automated testing, but
they do still help catch sanity checks. So we still manually test on staging
just to make sure that everything looks right before it goes to a prod.
Ultimately, we provide infrastructure to our customers, so reliability and
quality are important.
What are some recent examples of interesting development challenges solved by internal teams as part of building the product?
We’re basically building our own auto-scaling, serverless runtime for tasks, for
Airplane scripts. That involved figuring out the model of the control plane and
data plane, and figuring out the APIs between things. Working on load testing
this was a fun project that had tangible metrics as we saw latencies decrease.
Closer to the front end side, we’re building authoring experiences for people in
the browser. This involves building an IDE in the browser. How do you apply
Airplane-specific semantics to build an IDE? Can you write something, see the
preview; can you live-test it in your browser; can you collaborate with others?
Building a better authoring experience is something that we’re pretty excited
How does on-call work?
Every engineer is on call and we have just one rotation right now. This will
evolve as our company grows. With 11 engineers, everyone still has a good sense
of what the others are doing. The most important role of on-call is to be that
interrupt sponge for the week.
We do one-week rotations, although people have been known to trade slots. When
you’re on call, you’re looking at tickets, you’re looking at Sentry errors,
you’re getting paged if necessary. And then once a week, we do an on-call sync,
where we ask what noise there has been, how do we reduce that - what alarms have
you gotten; are they real issues, are they not? How do we shift priorities to
make sure that on call is not a big burden? We try to proactively manage that to
avoid getting to a really burnout-heavy on call rotation.
Hiring process at
How does the application process work? What are the stages and what is the timeline?
We move as quickly as the candidate needs; we’ve interviewed someone over two
days and given an offer out right afterwards, so we can move fast. But
generally, we like to meet with every candidate on a first call, partly to
introduce the Airplane, but also to get a sense for what the candidate’s
At our size it is about finding fit rather than purely selling someone. An
honest conversation about what is interesting and what’s not, helps candidates
really self-select. It turns out that when you’re working on an internal tool,
you get candidates who are very self-selected and really passionate about the
things that we’re building.
We like to do a two stage on-site where we go through a classic programming
challenge, where you can write code and solve hard algorithmic problems. We
don’t face that every day at Airplane, but once in a while you do, and that
difference between good and great engineers is how they adapt and face that. We
ask a system design problem; can you think about building blocks and how things
connect to each other and the abstractions there?
We also do a longerproject where we ask you to build an HTTP server to match
some sort of spec. We’ll tell you what it needs to do and what the endpoints
should support, and then you build it. We try to get something close to seeing
you produce real code. We’ve found that this gives a realistic sample of what
the candidate can do.
And then last, there’s an interview with co-founder and CEO, Ravi. Part of
that’s just answering any questions you have about Airplane, but it’s also to
get a sense for your values and how they align with Airplane’s.
What is the career progression framework? How are promotions and performance reviews managed?
We do performance reviews and we do give feedback to each other, but right now,
either this company works, or it doesn’t. So it doesn’t make much sense to look
at titles or career ladders.. Ultimately, your success and growth is based on
the success and growth of Airplane.
Console is the place developers go to find the best
tools. Each week, our weekly newsletter picks out the most interesting tools and new releases. We keep
track of everything - dev tools, devops, cloud, and APIs - so you don’t have to.
Subscribe to the weekly Console newsletter
An email digest of the best tools and beta releases for developers. Every Thursday. See the latest email.