Myths of no-code development
First of all, I want to note that the team and I are developing a no-code tool, and I think that the no-code platform has good prospects for its development.
However, recently a lot of not entirely accurate, and often mythological, information about the platform has appeared. This contributes to high expectations among newcomers. Such myths are produced both by no-code developers and all kinds of training courses. And they are more of an advertising nature than the real characteristics of the tools.
Before analyzing the myths, let’s consider the application development cycle on the code. 1) UX design development (40 hours), 2) UI design development (40 hours), 3) backend programming (120 hours), 4) android application programming (100 hours), 5) iOs application programming (100 hours) , 6) testing (40 hours). Here, the complexity of each type of work is given in hours for a simple application of 10 – 15 screens. Naturally, with an increase in the number of screens, the labor intensity will also increase proportionally. Here we do not take into account the work of PM (project manager).
These figures are average for several Ukrainian IT outsourcing companies. The order of work execution is parallel-sequential: UX design, UI design, programming (all three types are performed in parallel with some advance of the backend), testing. Thus, the total labor intensity is 440 hours, and the development time is 240 hours.
Immediately, we note that constructors based on templates of the AppsGeyser type are not considered here. They create an application in three steps: 1) Choose a template from 30 – 50 possible (a few clicks); 2) Add content such as app logo, title, text and links to customize your mobile app (about 10 minutes); 3) Download the app on the Google Play Store. Here, knowledge is really practically not needed, it turns out a native application. Unfortunately, there are dozens of templates, and millions of applications need to be developed.
Now consider the main myths.
Myth 1. Application development does not require specific knowledge.
This is claimed both by all kinds of no-code courses, and by the sites of some application designers. For example, on the website of the university of zero-coding they say: “You can easily master no-code tools and understand how to make money on it in a couple of weeks” and on the website of the Unicorn Platform constructor (https://unicornplatform.com/) write “Zero skills required”.
The rationale for this is that you just need to drag the necessary elements onto the screen, and the designer instantly implements this.
And this is exactly what the process of designing applications on videos that demonstrate the work of one or another constructor looks like. And all sorts of courses teach how to drag and drop elements in a particular constructor. There seems to be no cheating.
But remember that in the application development cycle there is the development of UX and UI design. In short:
UX design (User Experience – “user experience”) is responsible for how the application works.
UI design (User Interface – “user interface”) is responsible for how the interface looks.
With poor UX design, the application will be difficult to work with and not every user will be able to get the desired result. With poor UI design, the application looks at least ugly and it is also difficult to work with it.
Dozens of books are devoted to each type of design. Therefore, if a developer wants to get a convenient, beautiful application, he must know and be able to perform UX / UI design work.
They teach UX / UI in some universities. There are also a wide variety of courses. The time to master the skills of UX / UI design from scratch in the courses takes about one year.
In addition to general knowledge of UI design, mobile application development requires specific knowledge. For iOs it’s Human Interface Guidelines and for Android it’s Material Design.
It is worth noting that almost all app builders do not provide functionality for UX design. Probably the exception is GoodBarber (https://www.goodbarber.com/) is “a no-code app builder for people who are serious about design and UX.” As well as the DePro IDE, which highlights the functionality for both UX and UI design. DePro is currently in alpha testing.
In addition to design, there is an even greater layer of necessary knowledge – databases. Although most designers have their own tools for working with tables and convince users that this is no more complicated than Excel tables. But it is not so. This is a artisanal implementation of the microscopic part of the databases. The constructors provide functionality for describing tables and filling them with information (data entry, deletion, replacement). By the way, these functions are more fully and efficiently implemented in each DBMS. Out of the field of attention are such aspects of the database as design, queries (SQL), etc. Normal training in working with databases is carried out by universities. Although you can get a very superficial idea in the courses in a couple of weeks, But you won’t be able to do anything, but it will be clear how much you need to learn.
And the last nail. Many designers, such as Bubble, require knowledge of programming languages to implement some features. In particular, the bubble uses JavaScript.
It is interesting that companies involved in no-code development make real demands on candidates when hiring. For example, in the “Airtable Chat & Community” telegram chat, UDTech searched for no-code dev [mid; senior]with “technology stack: constructors – Bubble/Adalo/Flutter Flow, AirTable, Tilda; data – DB, SQL, noSQL, microservices, REST API; languages - JS, .Net, Python”.
Thus, after courses on constructors, you will be able (not really) to develop simple poorly and slowly working, ugly applications. And it will be until you master the above knowledge.
Myth 2. Constructors allow you to speed up and reduce the cost of application development by 10 or more times.
Indeed, constructors make it possible to speed up development, but not by 10-20 times.
To evaluate the real acceleration, let’s recall the application development cycle on the code.
It shows that the total duration will be 80 (UX / UI) + 120 (backend programming) + 40 (testing) = 240 hours. When using constructors (which allow you to develop the backend as well), we will have only 80 hours of development time. In total, we will develop 3 times faster using a no-code constructor than using code.
Let’s estimate how much cheaper it is to develop by designers. In this case, the total labor costs will be 440 hours. Those. with no-code it will be 5 and a half times cheaper.
These are the limit numbers. Further acceleration of development is possible only by reducing the time to complete UX / UI design. But in this case, the quality of the application will deteriorate, up to the refusal to use it.
Another myth from the area of speed of development is the message in some no-code courses that upon completion of the training, a copy of airbnb (Uber, Amazon Marketplace, …) will be written. Airbnb has over 500 IT people who are constantly improving the product. And no one is going to replace them with a “teacher” from the courses.
Myth 3. Applications created by designers are not inferior to native ones developed on code.
You can compare applications by various parameters. We will compare by functionality, which can be characterized by the number (variety) of functions available in the development of applications and the quality of these functions by the application.
The quality of functions execution depends on the technology on the basis of which the mobile application constructor is built. The main technologies are:
1. PWA (Progressive Web Application). They use such constructors as Bubble, Glide.
2. Cross-platform frameworks like React Native, Flutter. Uses such constructors as Adalo, Andromo.
3. Native code. Swift for iOS and Kotlin for Android. Native code is generated, for example, by AppMaster.
PWA, with all its advantages, is still developed by WEB tools and executed in a browser. Therefore, no matter how visually its elements are similar to the corresponding ones in native applications, they function differently (they do not work as smoothly, there are not many features, etc.). Gestures commonly used in native applications are also not supported.
Constructors using cross-platform frameworks create applications that work with native elements. But these applications have disadvantages: the size of applications is larger than that of native ones; performance is lower; security is low; increased battery drain. At the same time, React Native is significantly inferior to Flutter in terms of performance and application size.
No matter what technology the constructors are built on, they all have a limitation on the variety of functionality. All of them are focused on creating an MVP. Those. significantly inferior to native applications.
4. Easy to scale and expand.
Many (probably one in three) builders claim that they make it easy to scale and expand applications with their help. Scalability refers to the ability of an application to increase performance in proportion to additional resources. And extensibility is the ability to increase the functionality of an application.
In fact, constructors with their own data processing unit do not have the scalability property. Even the best ones, like Adalo and Bubble, using their own data tools, become very slow when the number of users grows over 1000. Designers use third-party tools to handle large datasets. But not all database constructors are scalable. In addition, the use of third-party tools leads to additional costs.
One of the no-code tools for backend development that has been actively used recently is Xano. The site declares scalability, incl. horizontal. However, there is no description in the documentation for implementing this property (probably not yet). The context implies scalability through the use of PostgreSQL. Horizontal scaling, perhaps, is understood as the ability to dynamically change the region of the server.
Therefore, there is no need to talk about full-fledged scaling yet.
Even worse with extensibility. Favorites among designers are Glide, Adalo, Bubble. All others are less efficient and do not have a significant customer base. But even these designers do not compete with each other. Each is used in a different range of sophistication of the applications that can be created with them. And if the capabilities of any constructor are not enough, they simply switch to another constructor and, in the end, after MVP, to the code.
Myth 5. No-code developers – millions.
For example, on the website of the bravostudio constructor (https://www.bravostudio.app ) states that they have 100+ thousand users. Application development time is several weeks. This means that during the year they will create about a million applications. Andromo (https://www.andromo.com/) – “More than a million users”, they “build multiple apps in no time”. Adalo on its website generally explicitly states that its users have created more than a million applications. There are many other constructors. And in total, we can expect that several million applications have been developed on no-code.
However, as we know, there are now about 1 million applications (including games) added to the Google Play Store each year. More apps are being removed. This is due to the introduction of new security policies and rules and more automated application verification, which often removes even normal and legal programs. As a result, the Google Play Store now has about 2.6 million apps. There are even fewer apps in the App Store.
Tellingly, there are no bursts of increase in the number of new applications in the statistics of new applications entering the stores. This means that in the Google Play Store, the share of applications developed with the help of designers is very small.
Therefore, the number of no-code developers and the number of applications developed by them is very much overestimated.
Conclusion.
1. No-code mobile application development tools will improve and take their place among other tools.
2. Marketing myths of the possibilities of no-code tools lead to high expectations of potential customers and, as a result, disappointment and abandonment.
