I've watched low-code go from a curiosity to a boardroom buzzword, and honestly, the hype caught me off guard. Five years ago, I dismissed it outright. Told a client their platform couldn't handle the complexity of their order-to-cash workflow. I was right about the limitations. I was wrong about dismissing it entirely. We built them a custom .NET application that took fourteen months and cost roughly four times what a low-code solution would have for their simpler processes. They'd asked us to evaluate both. I only evaluated the one I wanted to build.
That was a mistake I don't repeat anymore. The honest answer is that low-code and custom development aren't opponents. They solve different problems, and the real skill is knowing which door to walk through.
Custom development wins when you need control. I worked on a logistics platform for a shipping company that had to integrate with seventeen legacy systems, some of them running on protocols that predate the web. You cannot drag-and-drop your way through that. You need engineers who can write adapter code, handle edge cases that the low-code platform's designers never imagined, and debug at the protocol level at two in the morning. Custom code also shines when performance at scale matters. A client in the insurance space moved from a custom platform to a low-code one and hit a wall at around 800 concurrent underwriters. The platform couldn't optimize queries the way their original SQL team had. They moved the underwriting module back to custom and kept the claims intake on low-code. That hybrid approach saved them money and kept the business running.
Low-code wins on speed and empowerment. I've seen business analysts at a manufacturing client build internal tools that would have taken my team three months to spec, approve, and develop. They stood up a procurement dashboard in two weeks. Was it elegant? Was it scalable to enterprise load? No. Did it solve the immediate problem and let the business move forward? Absolutely. The danger is when organizations mistake that speed for universal capability. I've cleaned up two projects where a low-code platform became a dumping ground for everything, and within eighteen months the maintenance cost exceeded what custom development would have been. The platform's constraints become expensive when you fight them constantly.
The pattern I follow now is straightforward. If the process is well-understood, changes frequently, and the users are non-technical, low-code is my first instinct. If the logic is complex, the integrations are deep, or the performance requirements are non-negotiable, I go custom. Everything in between gets a hybrid conversation.
The worst decisions I've seen came from ideology. Teams who swore by custom code built slower than necessary. Teams who bet everything on low-code hit walls they couldn't climb. The technology choice should follow the problem, not the other way around.