I spent the first half of my career believing real enterprise software had to be custom. If you didn't write the code from scratch, you weren't solving the problem, you were just renting someone else's assumptions. That belief cost my team about six months and a very frustrated plant manager in Ohio.
We were building a production scheduling tool for a mid-sized manufacturer. Custom Java backend, Angular frontend, the whole thing. We interviewed the operators, mapped the workflows, and designed a system that could handle every exception we could imagine. The problem was we couldn't imagine all of them. Every Friday the plant manager would call with another edge case we'd missed. Shift swaps, machine maintenance windows, a customer who needed a rush order but only on Tuesdays. We kept adding features, and the go-live date kept sliding.
Meanwhile, one of our analysts built a quick prototype in a low-code platform just to mock up the UI. It took him three days. By the second week, the plant manager was using that prototype to actually schedule shifts, not because we asked him to, but because it was good enough. That stung. We had spent months arguing about message queues and database normalization while the business just wanted a screen that let them drag a job from Tuesday to Wednesday.
I'm not saying custom code is dead. Far from it. We still build custom services for things like real-time inventory matching across multiple warehouses, where the data volumes and latency requirements would choke most low-code platforms. But I've learned to ask a different first question. Instead of "what should we build?" I now ask "what can we buy or compose, and what genuinely has to be written by hand?"
The low-code prototype eventually became the actual scheduling tool. We threw away most of the custom backend and kept only a few custom microservices for the gnarly bits, like pulling live data from their ancient ERP. That integration was the real work, by the way. Low-code doesn't make legacy systems friendly. We spent three weeks just getting the platform to authenticate against a 20-year-old LDAP setup. A consultant I respect once told me the best low-code project is 80 percent configuration and 20 percent cursing at undocumented APIs. He wasn't wrong.
The moment I changed my mind came during a status meeting where the plant manager said he didn't care if the code was elegant, he cared if his schedulers stopped calling him at 5 a.m. to fix double-booked machines. I realized I'd been optimizing for the wrong audience. My pride wanted beautiful architecture. The business wanted a tool that worked before their busy season.
Now when a client asks about low-code versus custom, I tell them the answer depends on what they're trying to protect. If the application is a competitive differentiator with weird, evolving rules, go custom. If it's an internal workflow that needs to feel familiar and change quickly, don't overbuild it. The worst mistake is assuming every problem deserves a bespoke solution. Some problems just want to be solved.