The Computer Weekly Developer Network delves into low-code and no-code (LC/NC) technologies in a series of reviews designed to uncover some of the nuances and peculiarities of this approach to software application development.
By examining the basic mechanics of apps, suites, platforms, and services in this space, we seek to understand not only how apps are built this way, but also… in what form, form, function, and status these applications do exist…and what the implications are for enterprise software built this way, once it exists in live production environments.
This piece is written by Rishabh Kaoul from Appsmith – a low-code software company focused on enabling users to build in-house tools.
Kaul writes as follows…
There’s a reason some software tools are prohibitively expensive and it’s because they all share one common trait. They all have a “user-based” monthly pricing structure. The problem with this pricing strategy is that it does not take into account the heterogeneity of users.
Some users use low-code platforms daily for many hours (like developers or support agents), while others may only log in once a week for a few minutes (think managers who consult a dashboard) and many usage patterns in between. The user-based pricing system treats all users equally and charges them all at the same rate, assuming each user is a heavy user.
I believe low-code platforms with usage-based (not user-based) pricing is the way to go because it’s fair to users who only pay for what they use… and that’s exactly why our organization is adopting the usage-based model.
Integration with workflows
Developers and development teams face a number of issues when using low-code platforms to build their apps:
- Introducing change without breaking your app is daunting for developers. Changes can be lost… and reverting to a stable release can be a challenge. This is exacerbated when an app has thousands of users.
- Tools that provide versions for apps don’t integrate well with popular version control systems you use every day like GitHub or GitLab. You should therefore maintain separate workflows for each tool.
- Tools that provide versioning for applications do not sync well with good development practices; they have their own learning curve and general maintenance costs.
Development teams use a Git workflow to collaborate when building applications. It allows multiple developers to add their work to a Git branch, generate a pull request so peers can review their code, integrate with CI/CD pipelines so their changes go live when their pull requests are approved… and it provides a commit history to revert to a previous version in case something goes wrong.
It is important to have built-in version control through popular Git platforms (eg GitHub, GitLab). We decided to add it to our open source edition because we wanted the product to integrate very well with the rest of the development workflow.
Maintenance & customization
Appsmith’s Kaul: Customization is wise.
Low-code tools that are open source will be more beneficial to organizations. We decided to go open source because we wanted the core product to be accessible to everyone and to have bottom-up adoption.
With open source, you have the power to deliver critical features or integrations that matter to you. Personalization is inherent to in-house applications because every business is unique and this reliance on personalization increases with scale. So, having the ability to build new features even if they aren’t on the vendor’s immediate roadmap is another reason to embrace open source frameworks when it comes to low-code platforms for building custom apps.
We need a town…
This is where community becomes so important and why you want to get into a project that has a large, loyal, and growing community that is invested in contributing to the project. We see community members contributing new UI components (like this circular progress bar) and new integrations (like Say it again Where ArangoDB) all the time, as well as taking the initiative to report and fix critical bugs.
Frankly, something like ArangoDB wouldn’t have been a priority for us, but it was clearly for the person who built it and contributed it to our repository.
Having a community that cares and can contribute is a benefit that open source projects provide.
Finally, you control how you create, deploy, and secure your data. Due to the public nature of the code, it is easy to perform security audits against the code base to meet your infosec requirements. However, as with any open source project, it’s important to choose ones that are feature-rich, have good support, and have a growing community.