Visual builders and code-native platforms
Ravi Parikh, CEO of Airplane, on building an end-to-end internal tools platform
This reveals that the real split in internal tools is not low code versus code, it is whether the output behaves like normal software that engineering teams can live with long term. Retool is strongest when a team wants to assemble an admin panel quickly from tables, forms, and buttons. Airplane is aimed at teams that want the same internal app to sit in Git, plug into a monorepo, reuse libraries, and survive normal debugging, review, and extension workflows.
-
Retool won by saving engineers from hand building common internal UIs. Its sweet spot was fast CRUD apps on top of production data, then letting ops teams search records, approve actions, and trigger API calls with guardrails. That speed came from opinionated components and lightweight JavaScript, not from treating the app as a normal codebase.
-
Airplane started from the opposite end. It first turned scripts into shareable apps with permissions, audit logs, and notifications, then added Views so the read step and the write step could live in one workflow. That made it fit teams whose internal tools already begin as Python, JavaScript, and runbooks rather than as dashboards.
-
Appsmith shows the third path. It also targets internal tools, but competes on open source, self hosting, and lower cost. Even there, the battle is still largely against React and in house builds, which shows how often technical teams see these products as substitutes for custom software, not just for each other.
Going forward, internal tools platforms will separate more clearly into fast visual builders for standard ops work and code native systems for teams that want internal apps to behave like part of their software stack. As AI speeds up code generation, the advantage should shift further toward platforms whose output can be inspected, reviewed, and modified with ordinary engineering workflows.