Internal Tools Break Into Repeatable Jobs
Ravi Parikh, CEO of Airplane, on building an end-to-end internal tools platform
The core insight is that internal tools break into a small number of repeatable jobs, not an endless set of unique apps. Across Heap and Benchling, the same workflow kept appearing, support or ops needed to look up a record, inspect data, then run a controlled write action like a fix, deletion, or flag change. Airplane turned that sequence into product primitives, tasks for actions, views for reading, and workflows for multi step orchestration.
-
The repeated pattern starts with engineering interruption. Other teams hit edge cases in production systems, escalate to engineers, and engineers run one off scripts or babysit jobs. That is why script deployment, permissions, audit logs, and notifications were the first useful building blocks.
-
What looked generic in theory became concrete in practice. A support user rarely just runs a script. They first search for the right user or account, inspect matching rows, then trigger the write action. That forced Airplane to expand from script launcher into a full read plus write internal app builder.
-
This is also why the real alternative is usually React or in house admin tooling, not packaged SaaS. Retool framed the market around drag and drop CRUD screens, while Airplane framed it around developer owned code for recurring operational jobs. Both are responses to the same internal pattern, but with different assumptions about who builds and debugs the tool.
The category is heading toward more standardization around these recurring internal workflows. As AI makes code faster to produce, the winning platforms will be the ones that package the common scaffolding around those workflows, permissions, reviewability, and safe access to production systems, so teams can spin up bespoke tools in minutes instead of handing every exception back to engineering.