Purchase approvals run on a shared spreadsheet and an email chain. The operations team has asked IT for a proper tool, and the backlog for that kind of request is measured in quarters. Meanwhile, three people spend part of every week moving rows between files.
That gap between what operations needs and what engineering has time to build is where low-code platforms earn their place. This piece covers what low-code is, how teams use it, what IT and security should check, and where its limits are.
What low-code is
Low-code is a way of building software from prebuilt components and visual configuration, with code written only where it is needed. The platform supplies the parts every application repeats. The team supplies the business logic that makes this tool different from every other one.
What the platform handles is the repetitive groundwork:
Screen layout and components such as tables, forms, and charts.
Connections to databases, APIs, and SaaS tools.
Sign-in, user roles, and permissions.
Hosting, environments, and deployment.
What remains is the part only the team can define: which data the tool reads, which rules a record must pass, who approves what, and what happens next. Developers can still write SQL, JavaScript, or full components when the logic needs it.
Retool, Mendix, OutSystems, and Microsoft Power Apps are among the most widely used low-code platforms for internal tools and business applications.
How it works in practice
A typical build starts with the data. The team connects the platform to the systems that already hold it: a Postgres database, Salesforce, an ERP, a REST API. It then builds screens around that data and writes the queries and rules that move records from one state to the next.
Before release, it sets permissions by role and tests in a staging environment. Then it deploys to production. When the workflow changes, the tool is updated in place, without a rebuild.
The category has also moved closer to code. Retool's new app builder produces React apps. Developers write them in Retool's own chat and code views, or in a coding agent such as Claude Code. The agent connects through Retool's MCP server or CLI, and the app deploys to Retool. Retool supplies the hosting, version history, source control, and permissions on each data connection. It also supplies SSO, audit logs, and approval gates on writes to live data.
That layer of controls is what makes low-code useful at company scale. The code can come from a person, a model, or both, and every app sits on the same approved foundation.
What operations teams use it for
Low-code fits work where requirements change often and engineering time is scarce. Operations, support, finance, logistics, and product teams use it for:
Approvals. Purchase requests, refunds, price changes, and access requests, routed and recorded.
Admin panels. A safe screen over a production database, in place of direct SQL edits.
Consoles that join several systems. One view of a customer or an order drawn from the CRM, the order system, and the shipping provider.
Tracking and reporting. Live dashboards in place of a weekly export and a cleaned-up spreadsheet.
At Pico Clinics, clinics in North America and Europe ran on separate systems. One Retool platform now handles appointments, inventory, and billing across the network. At an e-commerce partner to luxury brands, a support console in Retool replaced up to six tools per ticket. Average handle time fell from 3 to 4 minutes to 30 seconds.
For where to start, see what operations teams automate first.
Low-code and no-code
The two are often confused. No-code tools rely entirely on visual configuration and are built for non-technical users. Low-code expects a technical builder somewhere in the loop and allows custom code wherever the logic needs it.
The difference matters most two years in, when the process has grown and someone needs to extend the tool. Low-code or no-code compares them in detail.
What IT and security should check
A low-code platform is a production system with access to company data. It should pass the same review as any other. The questions that matter:
Authentication. Does sign-in go through the company identity provider, with no local passwords?
Authorization. Can permissions be set by role, and on each data connection?
Audit. Is every action logged with the user, the time, and what changed?
Environments. Are development, staging, and production kept apart, with a controlled release path?
Data residency. Where is data processed and stored? Is a self-hosted deployment available if policy requires one?
Source control. Are changes versioned and reviewable, with a way to roll back?
Mature platforms answer yes to all six. The work is configuring them for each app, and keeping that configuration current as the team adds tools. The security and compliance checklist is the version a security team can forward.
Where its limits are
Low-code does not replace custom engineering everywhere. Three cases call for something else:
The software is the product. Customer-facing applications with their own design system and release cycle belong in a full codebase.
The architecture is unusual. Heavy computation, specialist data processing, or a domain model the platform's components do not fit.
The performance demands are extreme. Very high request volumes or hard real-time requirements.
Platform dependency is the other question to settle early. The practical answer is to keep core business logic in APIs and databases the company controls, and use the platform for the screens and workflows. That keeps the logic reusable by other systems, whatever runs the screens. Low-code or traditional development covers where the line usually falls.
Our view
We recommend low-code for internal tools where the workflow changes often, because the platform carries the repeated work and the controls IT expects. It suits teams that cannot spare engineers for internal work. We recommend custom engineering when the software is the product, because a product needs its own codebase, design system, and release cycle.
Before any build, decide where each piece of data lives, who owns the tool, and which controls IT needs to see. The product owner makes those calls with the people who run the process. We bring the architecture, the build, and the running of it.
