Airplane script to app platform

Diving deeper into

Ravi Parikh, CEO of Airplane, on building an end-to-end internal tools platform

Interview
It's a much older product, so it doesn't take advantage of a lot of really modern stuff, like serverless patterns
Analyzed 6 sources

The real advantage was not just newer infrastructure, it was a simpler path from one script to a safe, shareable internal tool. Airplane let a developer drop in Python or JavaScript, then automatically added the web form, permissions, audit trail, and notifications, which made ad hoc operations usable by support, ops, and engineering without standing up and babysitting extra infrastructure.

  • Rundeck came from runbook automation for incident response and infrastructure work. Its center of gravity was jobs, runbooks, and remediation for DevOps, IT, and security teams. That made it adjacent to Airplane's scripts wedge, but less naturally suited to everyday business workflows like support actions against product data.
  • What serverless patterns changed in practice was setup and ownership. Airplane described the old way as putting code behind an API, then building UI on top. Airplane collapsed that into script to app, so the team did not need to wire up web servers, auth, and logging just to expose a one off internal action.
  • This is why the scripts product worked as a wedge but not the whole platform. Teams could run write actions fast, but they still needed a read and diagnose layer to search records before taking action. Adding Views turned Airplane from a script launcher into a fuller internal tools product, closer to Retool and Appsmith.

The market has been moving toward platforms that bundle scripts, UI, workflows, and governance in one place. The winners are likely to be the products that keep the speed of serverless style execution, but also cover the full operator workflow, search, inspect, decide, then act, without forcing teams back into custom React apps or separate DevOps tooling.