Threats to Low-Code Platforms

Recently, Professor Andrzej Sobczak, in his article about threats to #LowCode platforms, shared his experience with a drastic increase in the prices of the platform he was using. He acknowledged that the biggest threat to #LowCode platforms is a lack of trust in these platforms and their creators regarding business terms.

I agree that this is a significant threat, but I think it applies not only to #LowCode platforms. Companies routinely use various IT solutions: ERP and CRM systems, industry-specific systems, integration solutions, as well as office suites, where changes in business conditions can be painful for customers.

Personally, I build trust in a particular solution based on trust in the technology itself and the organization that created it. The first type of trust involves ensuring that a given solution actually satisfies my functional needs and is based on modern technologies/frameworks, with a clear roadmap for its development. The second type of trust depends on how the solution provider treats its customers and partners. I agree with Tomasz Bykowski that a crucial aspect in all of this is a conscious investment in customer relationships and that Software is a human business.

Having worked on both the client and supplier sides, I have experienced two extreme situations. In the first case, a company that promised to deliver a tailor-made solution provided a system that did not meet our expectations and had numerous technical flaws. The supplier was aware of this and tried to address these issues with appropriate support. In the second case, a company with excellent technology struggled to manage relationships with its business partners effectively. In both cases, trust was severely damaged, and the possibility of further collaboration was ruled out.

Certainly, a significant issue associated with using commercial systems is vendor lock-in. While systems can be migrated or rewritten, it always involves substantial risk and costs. In the case of #LowCode solutions, some offer so-called source code export. In my opinion, even if it is possible, it may not be an entirely good solution. After such an export, we may obtain code that is difficult to understand and challenging to develop or maintain. Applications created in #LowCode tools often use standard components of the platform or functional libraries and tools needed for their operation. For instance, if an application uses a reporting module, a process engine, or an OCR library, it would need to be exported along with the code of these components. It's somewhat similar to applications in Spring Boot, which include an embedded application server (e.g., Tomcat) needed for their operation. Moreover, we purchase these platforms not to manage the source code afterward but precisely to avoid writing that code.

So, what is the solution? Building custom systems in traditional programming languages, utilizing a variety of ready-made frameworks that accelerate application development, believing that AI will soon be able to generate entire applications based on our requirements and ideas?

Personally, I believe that, for now, it's not entirely possible to avoid using ready-made commercial solutions, which always come with the risk of vendor lock-in. However, making a conscious choice of vendors based on trust in technology and the people creating it is a crucial factor that can somewhat reduce this risk.