Developer-Focused Internal Tools
Abhishek Nayak, CEO of Appsmith, on building an open source internal tool builder
This gap created room for a new kind of internal tools product, one built for engineers who already think in code instead of forms and dropdowns. In practice that meant connecting directly to production databases and APIs, writing JavaScript or SQL for logic, self hosting near sensitive data, and keeping apps maintainable enough that another developer could extend them later. That was very different from legacy low code products aimed at business teams and CIO buyers.
-
The real competitor was often not another vendor, but building the tool in React, Django, or scripts. Both Appsmith and Retool describe the core job as putting a fast admin UI on top of company data so support, ops, or finance teams can read records, update fields, approve workflows, or trigger actions like refunds.
-
Developer focus meant product choices that non technical buyers often do not prioritize. Appsmith emphasized self hosting, source code access, and the ability to extend missing connectors or widgets. Retool won with speed for common table and form workflows, but still required JavaScript and SQL, which limited true non technical adoption.
-
The category later split along two developer paths. Appsmith and Retool reduced front end work with a visual builder around common internal app components. Airplane pushed further toward code first workflows, where teams could turn Python or JavaScript scripts into governed internal tools with permissions, logs, and reusable UI.
Going forward, internal tools platforms are converging on the same destination, replacing one off scripts and hand built admin panels with faster, reusable layers on top of production systems. The winners will be the products that preserve developer control while removing the repetitive work of wiring auth, permissions, tables, forms, and workflows from scratch.