I spent five years arguing that low-code was the future of enterprise IT. I evangelized it in meetings, convinced my management to license a big-name platform, and even started a center of excellence. Then I got handed a supply chain forecasting module that needed to integrate with three legacy ERPs, apply machine learning to historical data, and present real-time dashboards to warehouse managers. The low-code tool couldn't even query one of the ERPs without a custom connector that took our integration team six weeks to build. And the forecasting algorithm? We had to offload it to a Python microservice and call it via API, which kind of defeated the point.
At the three-month mark, the project was supposed to be in user acceptance testing. Instead we were debugging a workflow that randomly dropped purchase order line items. The visual debugger showed everything green, but the data said otherwise. It turned out the platform's built-in transaction handling didn't play well with our message broker, and the workaround involved writing raw JavaScript that our junior developers couldn't maintain. I remember a conference call where the vendor's solution architect suggested we "just re-architect the process" using their premium add-on module. By then we'd burned through half the budget and trust from the business side.
I'm not saying low-code is useless. Far from it. Later that year we built an employee onboarding portal that pulled data from HR, IT, and facilities, all through drag-and-drop connectors. It was up in three weeks and handled thousands of new hires without a hiccup. The HR director called it magic. For straightforward CRUD, simple approvals, and forms that replace Excel spreadsheets, low-code is genuinely faster and anyone with process knowledge can own it. That's not nothing.
The hard part is drawing the line. Now, before picking a technology, we run a quick sanity check. Does the logic involve complex state transitions or nested conditional branching that doesn't map neatly to visual flows? Will we need to version-control the logic alongside application code, or is it self-contained? Can we test it automatically without a human clicking through screens? If the answer is "maybe not," we default to custom development, even if it takes longer upfront. I'd rather spend six weeks writing clean Python than six months fighting a platform's limitations.
The low-code vs. custom debate always gets framed as speed versus control, but that's too simplistic. It's really about understanding the problem's shape. Some problems are round, some are square, and if you shove a square problem into a round platform, you'll just end up with a lot of pain and a very expensive consultant bill. I still use low-code for the right things, but I don't evangelize anymore. I just ask, "What's the ugliest part of this workflow?" and listen. Usually the answer tells you everything.