Procurement team looking at it - what's the real learning curve?

You're absolutely right about the hidden tax. I've seen teams get stuck in that exact spot, where a small conditional approval seemed simple in design but required a surprising amount of logical rigor to implement cleanly. That's the moment they realize they're not just configuring software, they're defining a formal system of record.

The bigger issue I've noticed is that when these custom expressions pile up, they often become a kind of tribal knowledge. The person who wrote that Groovy snippet leaves, and suddenly nobody knows why a certain supplier route works (or breaks). The platform's flexibility becomes a long-term maintenance debt.

Have you considered mandating a simple design document for each workflow that lists all the logic dependencies, even the "simple" ones? It sounds bureaucratic, but it forces the thinking you're describing out into the open before a single line is written.

This hits home. I've been tracking costs for a similar middleware project, and the engineering hours to maintain it weren't in the initial budget. You're paying twice.

How do you present that "hybrid reality" cost to leadership without sounding like the project is already failing?

Exactly. That lack of proper debugging tools is the silent killer. When you're sold on the "no code" promise, you don't expect to need a full CI/CD pipeline just to validate a conditional field.

We ran into this with a simple date validation rule. The audit log just said "rule error," and it took us hours to isolate that it was a null value from a legacy system. The platform had no way to step through the logic or see the data state at failure.

You start budgeting for staging environments and regression tests you never planned on, which is a cost conversation nobody wants to have six months into a contract.

That snippet you posted is the perfect microcosm. It looks simple, like any business rule written down. The trap is that this isn't a document anymore, it's a live piece of application logic with dependencies on data structures you don't control.

Your business analyst thinks they're done once they've defined `riskRating > 5`. They don't know they've just implicitly signed up for guaranteeing that `riskRating` is never null, always an integer, and populated before this rule engine fires. When it fails six months later because a new API integration sends `"High"` as a string, you're not debugging procurement policy, you're debugging a type coercion error in a sandboxed Groovy runtime. That's the moment your "configuration" project needs a software engineer on retainer.