NoCode technologies have several well-known advantages: intuitiveness, out-of-the-box workflows, integration with external tools, and high development speed. Today we will look at the other side of the coin — the limitations and challenges that professional developers, system architects and product designers face in the context of NoCode. Apifornia aims to create a LowCode solution that eases the development process, so we focus on potential solutions to these challenges.

Maintainability of the program "code"

Supporting projects with complex architectures and large numbers of blocks proves to be either too difficult to implement or too costly.

Versioning and version control system. Because of the significant transaction costs incurred by companies using No- and LowCode solutions, the tools rarely provide support for versioning or commit creation typical of traditional version control systems such as git.

The lack of versioning and the absence of an analog of the git diff command makes it difficult to analyse situations when adding or removing nodes leads to a breakdown of the NoCode program. This also creates difficulties for team development: there is no work with several branches, no mechanics of code-review and code quality assessment before release to production. Even if it is possible to create several versions of the same code, there are no mechanisms to synchronise changes between versions or merge them into a final version like the git merge command.

Navigation and control of a large project. It should be noted that many developers in principle distrust graphical interfaces. The most effective variant of keyboard involvement is the terminal interface, which provides a wide range of ready and quick solutions compared to clicking in a visual environment. Even if we do not consider such a hardcore option, it is worth noting that most NoCode projects basically ignore the issues of effective navigation with hotkeys, as it is done in integrated development environments (IDEs), where you can not only use hotkeys, but also redefine key correspondences for easy transition from one environment to another.

Template solutions. As participants of the discussion on Reddit point out, one of the key problems is that NoCode templates do not always accurately realize the necessary concept. At such times, you either have to delve into writing the code or bring in experts who know the business. Recently, generative AI tools have largely solved this problem. In them, you can formulate a query in natural language and get the result in the form of program code. In addition, the AI assistant can explain what a particular part of the code does. Programming has become more accessible — the efficiency of tools is tilted in favor of LowCode platforms rather than pure NoCode solutions.

Code repackaging. Not all NoCode systems respect the principles of quality development. For example, for the sake of workflow simplification, they may ignore mechanisms for reusing parts of code as program components, often offering only the most basic method - copying blocks. This leads to code duplication, complicates project maintenance and updating, and increases scaling costs. However, there is also a reverse situation — the system may provide a necessary function, but the user may not understand its necessity or may not have the appropriate development culture.

Lack of development culture. NoCode developers usually have limited knowledge of programming patterns, which often leads to solutions for large projects becoming difficult to maintain. It is important to realise that the value of a developer who is actively involved in writing code lies not only in their knowledge of a particular development stack, but also in their practical understanding of the principles of designing complex systems.

It is clear that at the initial stages of program creation this aspect may seem less critical than, for example, overcoming the psychological barrier of a "clean sheet". However, as the project grows and the number of blocks used increases, the need for code refactoring tools becomes obvious.

Reliability in the long term

Difficulty of writing unit tests (unit tests). Users like reliability and readiness of building blocks of NoCode-tools. However, program debugging capabilities are limited - if something goes wrong in a block, it is often unclear how to fix the problem. NoCode platforms, except for open source solutions, do not provide tools for controlling, debugging and testing internal code. A developer usually cannot see the code created by the platform and cannot optimise the internal logic of program blocks for the task to be solved.

Vendor dependency. While in traditional development it is possible to move a site from one hosting to another without much difficulty, NoCode projects usually do not provide the option to export results, especially on basic tariffs. The lack of such an option means that the company is exposed to the risks of product withdrawal from the market or changes in tariff policy. Moreover, the dependency is often not limited to a single vendor, but actually extends to every vendor involved in the integration of the building blocks that make up the solution.

As a result, most users of NoCode tools use them primarily for prototyping and much less frequently for long-term solutions. Developers using such products perceive the choice of a NoCode solution as a technical debt that must be repaid in the future by replacing the NoCode prototype with a solution developed using traditional development methods. These concerns create a feedback loop that inhibits tool development: NoCode projects rarely face the challenges of large projects, are less likely to solve them, and are less prepared for such challenges.

Mismatch between the level of abstraction and the task at hand. In the GameDev community, LowCode solutions have become a sustainable option for increasing the level of abstraction, as in the case of blueprints in Unreal Engine. However, it is worth considering that this approach has emerged as a result of a need.

Critics of NoCode/LowCode emphasize that the graphical abstraction method is not always appropriate for the complex problems it is trying to solve, and that some problems are more naturally solved using classical programming. To illustrate this point, the following chain of abstraction level increase can be drawn:

physical level (hardware) → machine code → assemblers → low-level programming languages → high-level programming languages → low/no-code and/or generative artificial intelligence

As a result of design inconsistencies, it appears that NoCode programs sometimes duplicate libraries and frameworks available in traditional development that have a long history and are well tested for different usage scenarios. With this in mind, NoCode projects are expected to reuse these solutions and create a higher level of generalisation of the problem.

Security. Since most NoCode solutions are closed-source commercial products, developers face limitations when evaluating their security and are often distrustful of security issues. This can cause business concerns about potential liability in the event of a data breach.

In addition, it is important to consider the security aspect in the context of deploying NoCode tools. Today, most of them run through web browsers, which can introduce additional data security risks. Web applications can be exposed to attacks such as cross-site scripting (XSS) or SQL injection.

On the other hand, a limited number of NoCode solutions can be deployed on remote servers using Docker images, which can provide a greater level of security control and data isolation. However, even with this deployment, it is important to keep up with security updates and support to ensure that the system is robust.

Predictability of price and development time

Too many different tools. Simon Heuschkel's research paper The impact of no-code on digital product development demonstrates that startups are increasingly turning to NoCode solutions to create their products. However, the NoCode developer's experience with different platforms plays a significant role in this process. Without such experience, it becomes difficult to choose the most appropriate set of tools to successfully solve a particular problem. In fact, in NoCode development the positions of Developer and System Architect are much closer in meaning than in traditional development.

Small market for developer and consultant hiring. Finding a developer who specializes in a particular stack of traditional technologies is often a simpler task than hiring someone who specializes in NoCode. Due to the specific nature of NoCode solutions, developers typically work in a freelance format, and companies have to go to greater lengths to find a qualified individual with relevant experience. The demand for specialists continues to grow as NoCode becomes increasingly popular among companies looking to rapidly build and deploy digital solutions.

System Compatibility. NoCode is a broad concept that combines a variety of tools and approaches. This diversity allows one to enter the world of NoCode through 3D modeling or game development, and apply similar concepts to create both mobile and web applications. However, the commonality of NoCode approaches is usually only apparent at the level of working methodologies and mechanics, but not necessarily at the level of compatibility between different systems. Integrating different NoCode systems for different tasks often requires moving to a lower level of abstraction.

The costs of developing a product using NoCode, compared to a traditional development team, can vary significantly and be less predictable. In addition, the product development process itself using NoCode platforms can be less structured and less optimized compared to traditional development.

Conclusion

NoCode reflects current social trends in the world of technology, where people are increasingly using the Internet to achieve their goals. This approach is driven not only by the desire for convenience, but also by changes in team structures and increased competition.

NoCode does not completely eliminate the need for programming knowledge. Knowledge of development fundamentals remains a valuable asset, especially when working with more complex concepts such as databases, datasets, and search engines. Currently, API and program code skills, as well as general purpose interfaces, remain key components.

One of the key questions is the future of interfaces that are created in the NoCode paradigm. Some experts (e.g. Martin Russo in Generative AI vs NoCode in Web Development: A New Paradigm Shift) point out that in the near future graphical interfaces may become less important and applications will be more autonomous and learnable due to AI tools.