I spent the first half of my career convinced that real enterprise software had to be custom. Every line of code felt like craftsmanship. Then I watched a vendor demo a low-code platform and built a working purchase approval workflow in an afternoon. I felt stupid for ever arguing otherwise.
That feeling lasted about six months.
We rolled out a low-code inventory request tool for a manufacturing client. The first version went live in three weeks. People loved it. Then the edge cases started crawling out. They needed approval chains that branched based on item category, location, and budget code. The low-code platform handled simple rules fine, but the moment we needed to integrate with their ancient ERP's stored procedures, we hit a wall. The vendor's answer was a paid connector that didn't exist yet. The client's answer was "make it work." We ended up writing custom middleware in Python anyway, which defeated the whole point.
That project taught me the question is not low-code versus custom. The question is where the complexity actually lives. If the hard part is the workflow itself, low-code gets you to feedback faster. If the hard part is integration with systems that predate your youngest developer, no visual drag-and-drop tool is going to save you.
I made the opposite mistake too. At a previous job, we spent eleven months building a custom facilities management app. The requirements were a floor plan viewer, room booking, and a maintenance ticket form. Every one of those existed as a module in at least five off-the-shelf products. But our architect wanted control. We ended up with a bespoke codebase that took two full-time developers to maintain, and the floor plan viewer still didn't work on mobile. That was arrogance, not strategy.
What I've learned is to look at the cost of change before choosing a path. Low-code shines when business users will keep changing their minds, because you can throw away a screen without throwing away a sprint. Custom code shines when the system has to survive for a decade and talk to things that don't speak modern protocols. The messy middle is where most enterprise work lives, and that's where you need people who can switch between both modes without getting religious about it.
One habit I picked up after the inventory tool failure: before any build, I ask the business owner to describe the three edge cases they are most afraid of. If they can't name any, low-code is probably fine. If they immediately start describing approval matrix permutations that sound like tax law, we plan for custom code from day one. It's not a perfect test, but it's better than arguing about platforms in a conference room.
The real shift for me was realizing that low-code and custom aren't opposing philosophies. They're two sockets in a toolbelt. Use the wrong one and you'll strip the screw. Use the right one and nobody will care how long it took, because the thing just works.