I've been a proponent of low-code in the past (and may well be in the future), but we've been a bit burned recently with one of our suppliers - and it's not rea

I've been a proponent of low-code in the past (and may well be in the future), but we've been a bit burned recently with one of our suppliers - and it's not really a technical problem. Low-code platforms tend to come with complex licensing agreements, typically with variables for the size of the functionality developed, and the number of users - this left us in a sticky place when the supplier increased the cost for the functionality delivered without significantly increasing value delivered. Like all agreements, there are things you can do to increase value without exponential increase in cost, and we've done some of these. So the real issue is that the application architecture becomes license-driven rather than best-practice driven, and we paint ourselves into corners and reduce the overall value of the solution because of this. So my advice is not to avoid, but when you do proceed make sure that the cost increases are limited to CPI (or similar) for the same functionality (and don't factor an expiring discount into your ROI calculation - make sure it's worthwhile at the non-discount price). We've also had issues with branching, merging and version control, but that's secondary to the license-driven architecture problem.