Potential risks: - Vendor lock-in: if each low-code platform offers a different set of components and workflows, then it may be difficult to move to another if

Potential risks: - Vendor lock-in: if each low-code platform offers a different set of components and workflows, then it may be difficult to move to another if, for example, product cost becomes prohibitive at a later date. - Dishonest platform: unless the product provides an on-premises option (and many likely won't, partly because it is genuinely easier for users to get started with a cloud option), then both code and data is potentially available for the platform to inspect. - Business continuity risk: as with the previous risk, this depends on the availability of on-premise hosting (and/or product code available as FOSS run-it-yourself): if the low-code provider ceases to exist, then your business process (or perhaps entire business) may fail. There are some slightly more technical concerns that I have too: - Testing and source control don't always seem apparent or well-integrated, making me think that we are going to repeat some of the software engineering mistakes of the past. - Depending on the concepts and components exposed by low-code platforms, expressivity and capability can be (intentionally or unintentionally) limited. Integrating with an arbitrary weather forecast API that speaks an arbitrary protocol is possible using a generalized programming language - is it equally possible with each low-code platform? Democratizing technology is important and low-code will I'm certain help discover some excellent workflow improvements. However I think it is equally important to make it simple for someone to pick up a programming language -- that supports testing, source control, and so on (without requiring the user to know about them, initially...) -- and start on a path that will lead them towards established and recognized best-practices and an open, competitive ecosystem.