At the start of 2021, Gartner predicted that the worldwide low-code development technologies market will increase 22.6% this year. Of course, the data to prove them right or wrong will come in the future, but it seems that even non-technical people are familiar with the term these days since the digital transformation (in large part accelerated by no-code and low-code solutions) has been playing out before the public’s eyes.
Whether you’re all aboard the low code hype train or aren’t convinced, we must acknowledge the tangible benefits these solutions are already bringing to the world.
Suppose you’re a business owner looking to automate paper processes, manage contacts and communication through a CRM, or create a website quickly and easily. In that case, low-code is an excellent way to go.
Low code can be a helpful tool to build an MVP and flesh out a concept within a small scope with precise product requirements and limited plans to scale. However, when a project naturally develops, one will also need to upgrade the processes. With low-code solutions, scaling is painful, costly, and limited.
From a professional developer’s perspective, going the low-code route to complete small-scale projects and prototypes or build basic solutions is quick and mostly painless. However, most professionals will prefer to code from scratch when working on complex applications because of the flexibility. There is always the chance that a low-code platform won’t allow you to create a product that meets new or changed requirements.
At best, low code is a workable tool, but at worst it is a bad long-term investment. Why?
Scalability is a key issue
The opportunity for and cost of horizontal and vertical scalability are vital factors when choosing a vendor. Number of daily active users, available features, storage, and computing power are just some factors to consider.
For example, if you’re looking to build an online store, consider whether the vendor you’re choosing to do it with caps your traffic or throttles access. If your site experiences an influx of visitors, they will limit access and force you to upgrade or lose business. What’s worse, this decision is made by AI and is non-negotiable. Large providers in the website/store builder SaaS niche have been known to shut down clients’ accounts and stop responding altogether.
Beyond that, short-term thinking, continuously changing requirements on the business end, and lack of a systemic view will result in technical debt that silently constrains the growth of your business.
Going for the solution that’s best for the organization as a whole is not always the most attractive choice for managers thinking within the scope of their department, which results in developers having to support out-of-date ramshackle code. It’s a famous gripe among devs, and so is the following.
Extensive training requirements
Extensive training will be the first requirement to implement a low-code solution. This can significantly delay deployment, even to the point where the low-code approach no longer wins over agile development in time to market.
After shopping around for a car, negotiating with a salesperson, paying, and getting the keys in your hand, you can drive away a satisfied customer. But when you purchase access to a low code solution, you need to go to driving school all over again. Developers must first onboard themselves and learn how to work within a new system. They have to effectively learn how to use a new environment and nullify any experience they bring to the table.
Timeframes will vary from weeks to months and will depend on the quality of the available documentation and support. There is no industry standard, and every platform will have its own unique system.
And implementing is only a piece of the puzzle. The real problem begins when a problem occurs and someone needs to fix it.
Troubleshooting is difficult
In the best-case scenario, you laid out the plan for your project early on, picked a suitable solution, built it, and now it works well to satisfy your needs.
But something will inevitably break, as it always does. Again, depending on the quality of the documentation, the response speed, and competence of support, the dev team may need considerable time to study and fix the issue because the same shortcuts that made development easy can hinder maintenance.
Debugging a program made with a low-code solution may be difficult or flat-out impossible since developers have no access to the infrastructure the code uses to function. The developer may not know whether the error is on their end or the vendor’s. Tracking down a problem may produce a dead end when you cannot ask their developer team questions directly.
And if it turns out to be a cybersecurity vulnerability, you’re out of luck.
Vendor lock-in
Your low code solution will not be compatible with any other competitor or similar provider. Even if you can export the source code, it will necessarily depend on the vendor’s platform to work, and you can only make use of it as a backup.
Depending on the solution, integration options, webhooks, and APIs will be available to add to the stack and your monthly SaaS bill. And while industry CEOs justify the high initial price by reduced costs over time, they can be challenged by problematic maintenance and difficulty in making upgrades.
If you’re in too deep and realize it’s time to migrate to another service, you will find that it’s impossible. The proprietary system your team has learned to use and finessed to work in a way compatible with requirements on the business end will now have to be abandoned, and you may need to start the process all over again from scratch.
No code and low code are here to stay, but the revolution is perhaps a misnomer. These solutions, powerful though they are, are only another tool in a professional’s kit. That is, they are to be deployed only when called for.
Low code is cookie-cutter, but it works, and that’s the point. Of course, no one expects these tools to shatter expectations or redefine norms, so if you need a short-term solution, if you’re building an MVP, or if you need something standard like an online store, go this route. But before you commit, make sure you have a deep understanding of the niche you’re working in so that you can clearly formulate demands for the product you’re building and test them against a vendor’s capabilities.
Reviews are key, of course, but ask your developers to study the documentation and give their assessment of any given product before signing the contract. The best bet are vendors with lots of users who provide platforms for developers to communicate and have a rich library of easily searchable materials.
Lastly, watch out for red flags like delays, inaccurate documentation, and questionable competence of support during development. It’s never too late to pull the plug if something isn’t working.
