Code ownership versus builder lock in
Ravi Parikh, CEO of Airplane, on building an end-to-end internal tools platform
The real split here is not open source versus proprietary, it is code ownership versus builder lock in. Airplane is arguing that if an internal tool lives as normal JavaScript or Python inside a company repo, engineers can review it, version it, reuse libraries, and move it over time. A visual builder that stores the app in its own product specific model can still feel closed, even if the platform itself is open source.
-
Retool won by letting developers wire tables, forms, and queries onto a production database in about a day instead of building a full React admin panel over a couple of weeks. That made the category feel like a faster UI layer for internal CRUD work, not a normal software project.
-
Appsmith pushed that same core internal tool builder into an open source and self hosted package. Its appeal was concrete for teams that wanted database access to stay inside their own infrastructure, and for engineers who wanted to inspect or modify connectors and widgets.
-
Airplane tried to win on a different axis. It started from scripts, scheduled jobs, approvals, and workflows, then added Views so support and ops teams could inspect data and trigger actions in one place. That made its pitch closer to build with code, then ship an internal app around it.
Going forward, internal tools platforms should keep separating into two lanes. One lane looks like visual builders that maximize speed for standard dashboards and forms. The other looks like code first systems that fit directly into engineering workflows. As AI makes code cheaper to write, the code first lane should get stronger.