Disable ads
Launch sales in new markets
For example, in China and India – a free business training program will help
Many people have business ideas in their heads, but the salaries of programmers are so high that it is impossible to realize them without investments.
No-code constructors are simpler than programming languages, which allows you to master them in a few weeks or months, and independently develop and launch a product without involving programmers.
The third reason is development speed.
When it comes to testing hypotheses, speed is important and quality comes second.
This is the reason landing page builders have become so popular. Not due to quality, but due to the speed of development. And the quality improves over time.
All this together creates a demand for development without code. But not everything is as smooth as it might seem.
Current No-code Issues
Let’s take a look at the reverse side, and for the sake of symmetry, here are three disadvantages that can make you abandon No-code.
The first disadvantage is dependence on constructors
There is nothing you can do about problems on the constructor side. You can’t fix bugs that annoy you, you can’t change the priority of development tasks.
You don’t have access to the code, and if the constructor doesn’t work for some reason, then your project won’t work either. In other words, constructor problems are your problems too.
The second drawback is the limited capacity
Every constructor has limitations, and what seems like a simple task may not be feasible on a constructor. Even if you involve professional developers, not all restrictions can be bypassed.
You have to make compromises and look for workarounds, or completely abandon development without code.
The third disadvantage is poor scalability
The more complex the project, the more likely it is to fail when implementing it on constructors. And the slower it will work, and you have few optimization tools, since there is no access to the code.
And the more complex and larger the project, the higher the tariff you will need, and at some point it ceases to be profitable.
Over time, No-code solutions become more reliable, scalable and flexible, but there are still disadvantages.
Can No-code replace programming?
According to my subjective assessment, of what a professional developer can do, only a few percent can be repeated in No-code. I’m a developer myself, and I can imagine the difference.
Most often, I come across the argument that in No-code it is impossible to do some specific tricky thing from the personal experience of the interlocutor. The examples are different – either integration, or synchronization, or a feature of the interface, whatever.
From a recent
The argument is valid, but the question itself is posed incorrectly.
The correct question looks like this:
Can programming replace No-code?
When someone solves his problem on the constructor, the world becomes one less task for programmers. It may seem like a drop in the ocean, but that’s what’s happening.
Over time, the designers will be able to collect more and more complex projects. With a personal account, subscription, personalization, a complex interface, and so on.
Now in No-code services you can collect landing pages, small websites, online stores, online courses, marketing auto funnels and chat bots. The list will only grow.
This process will stop only if good programmers suddenly become much cheaper. Then the need for No-code may fall, and until then the demand will grow, because for a number of tasks it is faster and cheaper.
Nobody will replace anyone
Programmers will not be left without work, there will simply be fewer simple, same-type, template tasks. These tasks will increasingly be done without any code at all, but it is too early to say that programmers will not be needed.
After all, someone has to develop the No-code tools themselves.
Today I want to raise the problem of building a project when it has both a website and a mobile application. It is on this issue that conflicts very often arise between programmers who approach the task from a development point of view and want to do everything perfectly, and clients who are primarily interested in the economic side of the issue.
And there are especially many conflicts in cases where a business already has a website, and it suddenly needs a mobile application.
An example from my own experience: not so long ago I was approached by guys who have their own network of specialized oil change services. They work with all models and specialize in fluids (mainly oil, but they change other fluids too). They are presented in several cities, the working scheme of their service can be depicted as follows:
There is a site to which visitors come;
After registration, they have access to a personal account, a client card, ordering any services;
in the inner loop there is 1C, into which applications fly away from customers, where they are then successfully processed;
part of the data is returned from 1C in the form of viewing records, data on the next replacement, and so on.
In general, nothing unusual: everything is plus or minus like in a trivial online store, only instead of goods there are services, and you need to sign up for the station. And now they faced the issue of developing a mobile application.
Reference approach
The classic approach of programmers to development looks like this:
First, some server part is done,
The admin panel is attached to it,
From the server there is an integration with the internal ERP
Only then a website and a mobile application are made to this backend
Both the site and the application, in this case, play the role of a frontend: both display data from the server, representing a tool for working with data not for the administrator, but for end customers. It turns out the classic infrastructure of a classic client-server application: everyone is happy, everyone is happy.
However, everything is not always so smooth: in the example above, the site and the server part are combined. earlier they had just a corporate website, and then it was developed to a service with a personal account. It turns out that in order to do everything for good, you need to demolish what previous programmers have done in a few years and do it right from scratch.
The problem is precisely in the approach to architecture based on what has already been done. Most often, programmers insist that the old scheme should be forgotten and rebuilt, justifying it with previous crutches and the need for refactoring, taking into account new tasks. On average in the market, this costs one and a half to two million, and in time it takes about a year, taking into account testing and debugging.