A few years ago, I led a project to replace a thirty-year-old claims system at a mid-sized insurer. The business users were desperate for anything that wasn't green-screen. A low-code platform promised drag-and-drop forms, visual workflows, and a three-month timeline. We were sold.
We mocked up the first few screens in a week. The demo wowed executives. Then we hit the actual claim adjudication logic. The business rules were Byzantine — disability claims that depended on state law, age, policy riders, and historical court interpretations. The low-code tool handled simple 'if-then' but choked on nested conditions with exceptions. We spent days building workarounds with custom scripts embedded in the platform, which defeated the purpose.
The worst moment came during a pre-launch audit. The system couldn't correctly calculate a specific type of partial benefit. The low-code vendor's support suggested a patch that would break other rules. We ended up pulling the plug for two weeks while three developers rewrote that entire module in Java, using the low-code platform as a glorified front-end. I remember sitting in a conference room at 2 AM, apologizing to the risk manager, knowing I'd misjudged the complexity.
That experience didn't make me hate low-code. A year later, I used the same platform to build an onboarding app for new hires — forms, document collection, HR approvals. It took four weeks and still runs without issues. The difference? The workflow was straightforward, with no deep integrations or legal nuance. I also built a simple inventory tracker with it, and that worked fine.
Now I have a simple litmus test: if you can't explain the core business logic to a smart intern in ten minutes, don't low-code it. Custom development isn't slower when you factor in debugging a platform's constraints. I also insist on mapping all edge cases before choosing a tool. It's amazing how many projects fail because we skip that step. The real choice isn't low-code versus custom; it's 'does the platform's abstraction actually simplify the problem, or does it just hide it until launch?'
I still keep that claims system's postmortem on my desktop. It reminds me that speed of development means nothing if you can't handle the business reality on day one. These days, I start every project by sitting with the people who do the work, not the architects. The answer they give tells me which path to take.