The low-no-code series – Appsmith: Let’s move from user-based to usage-based
The Computer Weekly Developer Network gets high-brow on low-code and no-code (LC/NC) technologies in an analysis series designed to uncover some of the nuances and particularities of this approach to software application development.
Looking at the core mechanics of the applications, suites, platforms and services in this space, we seek to understand not just how apps are being built this way, but also… what shape, form, function and status these apps exist as… and what the implications are for enterprise software built this way, once it exists in live production environments.
This piece is written by Rishabh Kaul from Appsmith – a low code software company focused on enabling users to create internal tools.
Kaul writes as follows…
There is a reason why some software tools are prohibitively expensive and it’s because they all share one common trait. They all have a monthly “user-based” pricing structure. The problem with this pricing strategy is that it doesn’t take into account the heterogeneity of the users.
Some users use low code platforms daily for many hours (like developers or support agents), while others might log in only once a week for a few minutes (think managers checking out a dashboard) and a whole lot of usage patterns in between. The user-based pricing system treats all the users alike and charges them all at the same rate, assuming that every user is a heavy power user.
I believe that low code platforms with usage-based (not user-based) pricing are the way forward since it’s fair to the users who only pay for what they use… and this is exactly the reason our organisation is adopting the usage-based model.
Integration with workflows
There are a number of problems faced by developers and development teams while using low code platforms to build their applications:
- Introducing a change without breaking your application is daunting for developers. Changes can be lost… and going back to a stable version can be a challenge. This is exacerbated when an app has thousands of users.
- Tools that provide versioning for apps, don’t integrate well with popular version control systems that you use everyday like GitHub or GitLab. So you have to maintain separate workflows for each tool.
- Tools that provide versioning for apps also don’t sync well with common and good development practices; they have their own learning curve and maintenance overheads.
Development teams use a Git workflow to collaborate while building applications. It allows multiple developers to add their work in a Git branch, raise a pull request so that their peers can review their code, integrate with CI/CD pipelines so that their changes go live when their pull requests are approved… and it provides a commit history to go back to a previous version if something were to go wrong.
It’s important to have built-in version control via the popular Git platforms (GitHub, GitLab for example). We decided to add it to our open source edition because we wanted the product to fit very nicely with the rest of the development workflow.
Maintenance & customization
Appsmith’s Kaul: It’s wise to customise.
Low code tools which are open source are going to be more beneficial to organisations. We decided to go open source because we wanted the core product to be accessible to everyone and be adopted bottom up.
With open source, you have the power to contribute critical features or integrations that matter to you. Customisation is inherent to internal applications, since every company is unique and this dependency on customization increases with scale. Thus, having the ability to build out new features even if they aren’t on the vendor’s immediate roadmap is another reason to adopt open source frameworks when it comes to low code platforms for building custom applications.
It takes a village…
This is where community becomes so important and why you want to be going with a project that has a large, loyal, and growing community that is vested in contributing back to the project. We see community members contributing new UI components (like this circular progress bar) and new integrations (like Redis or ArangoDB) all the time, as well as taking the initiative to report and fix critical bugs.
Quite frankly, something like an ArangoDB wouldn’t have been a high priority for us, but it clearly was for the person that built and contributed it to our repository.
Having a community that cares and can contribute is an edge that open-source projects offer.
Finally, you have control over how you build, deploy, and secure your data. Due to the public nature of the code, it’s easy to perform security audits on the codebase to meet your infosec requirements. As with any open-source project, however, it’s important to choose those that are feature-rich, have good support and have a growing community.