What is low-code? A plain-English FAQ

What is low-code? It is one of the questions we are asked most often by operations and IT directors who have seen the term in a vendor pitch or a board pack and want a straight answer before anyone signs anything. The short version: low-code is a way of building software where most of the application is assembled from visual tools and pre-built components, with hand-written code reserved for the parts that genuinely need it. The longer version is worth five minutes, because whether low-code is the right call depends entirely on what you are building.

Below are the questions we hear most, answered the way we would answer them across a table.

What is low-code?

Low-code is an approach to building applications that replaces much of the traditional line-by-line coding with configuration. Screens, forms, data tables and simple workflows are put together in a visual builder. Where the built-in pieces run out, a developer writes conventional code to fill the gap, which is what separates low-code from "no-code" tools that offer no escape hatch at all.

The appeal is obvious. A working internal tool that might take a development team weeks to build from scratch can often be assembled in days, because nobody is re-implementing login screens, form validation or database plumbing that the platform already provides.

The catch is equally simple: you are building inside someone else's product. The platform decides what is easy, what is awkward and what is impossible, and those boundaries only become visible once you push against them.

What is a low-code platform?

A low-code platform is the commercial product that makes all of this possible. Microsoft Power Apps and Power Automate, OutSystems, Mendix and Retool are the names that come up most often, and each bundles roughly the same ingredients:

• A visual builder for screens, data models and workflow logic.
• A library of pre-built components, from date pickers to approval chains.
• Connectors into common business systems such as Microsoft 365, Salesforce and SQL databases.
• Hosting, user management and security handled by the platform.

Platforms differ in emphasis. Power Apps is strongest inside a Microsoft estate. OutSystems and Mendix target larger, more complex applications. Retool is aimed squarely at internal tools built on existing databases and APIs. All of them charge by subscription, usually per user per month, which matters more than it first appears: an application used by two hundred staff carries a licence bill that compounds every year it stays alive.

What is low-code development, and who does it?

Low-code development is the practice of building on these platforms, and the most common misunderstanding is that it is not really development at all. Vendors lean on the phrase "citizen developer" to suggest anyone in the finance team can build the applications the business needs.

Our experience is more measured. The visual builder removes typing, not thinking. Someone still has to model the data sensibly, design workflows that survive real-world exceptions, manage who can see what, and connect the application to the systems around it. For a simple leave-request form, a capable analyst can absolutely do this. For anything that touches money, customers or compliance, you want the same engineering discipline you would apply to any other system, whatever tool it is built with.

There is also a governance question that arrives quietly. When building becomes easy, applications multiply. Without someone keeping an inventory, agreeing standards and watching the licence count, a business can find itself running forty small applications nobody fully owns. The sprawl, rather than any single bad app, is the failure mode that hurts.

When is low-code the right investment, and when is it not?

Low-code earns its keep when the problem is common and the solution does not need to be distinctive. In practice that means:

• Internal tools and admin screens, where staff will tolerate a standard-looking interface in exchange for getting it this month rather than next quarter.
• Approval and request workflows: leave, purchasing, onboarding checklists, expense sign-off.
• Forms-over-data applications that read and update records in systems you already run.
• Prototypes, where the goal is to test a process before committing to a full build, or before deciding whether an off-the-shelf product should be replaced at all.

It fits poorly at the other end of the spectrum. Systems that differentiate the business deserve to be exactly what the business needs, not the nearest shape the platform allows. Customer-facing products need a level of polish and performance that visual builders struggle to deliver. And applications with demanding integration needs or high transaction volumes tend to hit platform ceilings at precisely the moment they become important. That territory belongs to Custom Software, where you own the code, the behaviour and the roadmap outright.

Cost cuts both ways too. Per-user licensing looks cheap in month one and expensive in year four. For a small team the subscription is trivial; for a few hundred users it can overtake the cost of building and running a custom application. The honest comparison is total cost over three to five years, not the price of getting started.

How do we approach low-code in practice?

We build custom software for a living, and we still recommend low-code regularly, because the sensible question is never "which technology do we prefer?" but "what is the cheapest thing that will still be the right thing in three years?"

When a client brings us a candidate application, we look at four things: how central the process is to the business, how many people will use it, how much the requirements are likely to change, and what it has to connect to. The answers usually sort the estate cleanly. Routine internal workflows go to a low-code platform. The core systems the business competes with are built properly, once. And the two halves are joined through deliberate System Integration, so data flows between the quick wins and the core without anyone re-keying it.

The pattern we steer clients away from is the accidental one: a low-code tool adopted for a small job that quietly becomes load-bearing, until the business depends on an application that was never engineered to carry it.

Deciding between low-code and custom software?

If you are trying to decide whether a specific application belongs on a low-code platform or in a custom build, that is a conversation we have most weeks, and it is usually a short one. Bring us the process, the user count and the systems it needs to talk to, and we will give you a straight recommendation, including the times the answer is "buy the subscription, do not pay us to build it". Talk to us.