I spent the first half of my career as a custom app purist. If you asked me about low-code platforms five years ago, I would have told you they were toys for business analysts who didn't know how to handle a real transaction. Then I inherited a legacy system built on one of those toys, and I had to eat those words.
The system was a mess, but not for the reasons I expected. The business logic was solid. The workflows actually matched how people worked. The problem was that the platform had changed its licensing model twice, and we were locked into a version that no longer got security patches. We couldn't migrate because the customizations were too deep. We couldn't rewrite because the budget was gone.
That experience changed how I think about the low-code versus custom debate. It's not a technology question. It's a risk question.
When you build custom, you control everything. You choose the framework, the database, the deployment strategy, the monitoring tools. You also own every bug, every dependency that goes out of support, and every developer who might leave and take the undocumented knowledge with them. Custom gives you freedom, but freedom comes with a maintenance cost that most organizations underestimate by a factor of three.
Low-code platforms promise to abstract away that complexity. The trade-off is that you're betting on the platform vendor staying alive, staying reasonable with pricing, and not pivoting their product roadmap away from your use case. I've seen that bet pay off exactly once, for a supply chain application that needed to be built in three weeks and had a shelf life of eighteen months. It was perfect for that.
I've also seen it fail spectacularly, like the time a manufacturing client built their entire quality management system on a low-code platform, only to discover that the platform couldn't handle the data volume from their IoT sensors. The vendor told them to upgrade to the enterprise tier, which cost more than hiring three developers to build it from scratch.
The real insight I've landed on is that the decision comes down to how much uncertainty you're willing to absorb. Custom development absorbs uncertainty in the build phase—you don't know exactly how long it will take or if the architecture will hold. Low-code absorbs uncertainty in the operations phase—you don't know what the platform will cost next year or if it will scale.
I now use a simple heuristic. If the problem is well-understood and unlikely to change, custom is usually the right call. If the problem is urgent and temporary, low-code can be a lifesaver. But if the problem is complex and strategic, neither approach is safe without a clear exit strategy.
These days I tell teams to think about what happens when the low-code platform changes or when the custom app's original developers move on. If you can't answer that question with a straight face, you're not ready to build anything.