Where low code fits, and where it does not

Low code has spent a few years being sold as the answer to everything, which is the surest way to make people distrust a genuinely good tool. We have built with low code since long before the term was fashionable, and the honest position is the one you would expect from anyone who has used a thing for real. It is excellent for some work and a poor choice for others, and the skill is knowing which is in front of you.

Start with where it fits, because that is most of what mid sized businesses need. Low code shines when you are building the systems that run an operation. The way jobs move through your business, the way information is captured and shared, the screens your team uses every day, the logic that is specific to how you work. This is software that needs to fit your business closely and keep changing as the business changes, and that is exactly low code's strength. You can build something that fits properly in weeks rather than quarters, and you can keep adjusting it without a heavy release every time the operation shifts. For the distinctive, evolving heart of an operation, it is hard to beat.

It also fits where the alternative is no system at all. Plenty of businesses are running critical work on a sprawl of spreadsheets and goodwill because a full custom build always seemed too expensive to justify. Low code changes that maths. The thing that was never worth a six figure project becomes very much worth a few focused weeks, and the workarounds can finally retire.

Now the limits, because they are real and we would rather name them than have a client discover them later. Low code is not the right tool when you need extreme performance or scale, the kind of load where every detail of how the software runs has to be tuned by hand. It is not the right tool for the commodity systems we discussed elsewhere, the payroll and accounting that you should simply buy. And it strains when people try to use it to build something genuinely enormous and intricate, a system so large that the very ease of changing it becomes a liability, because a sprawling low code application can tangle just as a sprawling spreadsheet does.

There is a quieter limit too. Low code makes building easy, which means it makes building badly easy as well. Without someone thinking about the data underneath and the shape of the whole, you can produce a fast mess instead of a slow one. The tool does not supply the judgement. That still has to come from people who have done it before.

Where does AI sit in this. Mostly, low code is how we build the operation that gives a model something clean to work with, and how we wire the model's help into the daily flow once it is ready. The low code system holds the truth and the process. The AI reasons on top. Used for what it is good at, with clear eyes about where it is not, low code is one of the most useful tools we have. The trouble only ever starts when someone forgets it is a tool and starts treating it as a religion.