Airplane code driven internal tools
Ravi Parikh, CEO of Airplane, on building an end-to-end internal tools platform
This reveals the core split inside internal tools, between screens that display and edit data, and systems that run real operational logic. At Heap and Benchling, the painful work was not making a form. It was searching for the right account, kicking off a Python script, waiting for it to finish, controlling who could run it, and keeping an audit trail. A UI builder solved only the front layer, not the full job.
-
Airplane started from the script side for exactly this reason. The first product let a team take an existing internal script and wrap it with permissions, notifications, and logging. That fit cases like data fixes, backfills, and admin actions that already lived as engineering runbooks, not dashboard widgets.
-
The missing piece was the read step before the write step. Support or ops teams usually need to search for a user, inspect matching records, then trigger an action. That is why teams paired Airplane with Retool or an in house admin tool, then copied IDs between them, until Airplane added Views.
-
This is also why Airplane positioned less against Retool and more against building in house. Retool’s historical strength was fast CRUD style apps for ops teams. Airplane went after developer owned workflows where the valuable asset was the underlying code, version control, and repeatable execution of scripts and multi step jobs.
The market is moving toward platforms that combine both layers, basic data exploration in one place, and code driven actions in the same workflow. That favors products that can turn existing scripts and runbooks into safe internal software, because the next expansion of internal tools will come from replacing manual engineering interventions, not just replacing spreadsheet style admin panels.