Internal tools are critical pieces of software inside businesses, spanning across functions, and taking up significant developer bandwidth. These are typically custom built.
Low-code tools have started gaining popularity, since they make application development easier for developers, via their visual nature where you “drag and drop” elements, simplify application management and deployment, and have built-in version control.
Their visual nature, along with collaboration features like real-time commenting, enhances the feedback process between technical and non-technical teams, making the internal tool development more inclusive.
The challenges of low-code platforms include potentially less flexibility and customizations as compared to custom software frameworks.
Choosing an open-source low-code platform with a vibrant community offers unique benefits such quicker bug fixes, ability to contribute features that don’t fall in the low-code provider’s roadmap, and greater control over security.
Internal tools are the lifeblood of all growing and established businesses. These are often highly-customized technical tools, platforms, and libraries built to increase the productivity of other product teams and support internal operations
They come in many forms, from a simple GUI over a database to CRUD interfaces that are used by support teams (for example, issuing refunds) to complex workflow automation (for example, allowing your engineering team to manage its AWS instances).
I have spent a large part of the last decade building these tools within large organizations like Flipkart (the largest e-commerce site in India) and have seen firsthand both the benefits these tools provide as well as the challenges one encounters to build and maintain them. This problem bothered me so much that I decided to start an open-source project in this space, Appsmith.
Regardless of what they’re used for, there are a couple of things that are common across the board when it comes to internal tools in organizations.
Firstly, beyond very simple use-cases, most of these tools are still built by developers. The genesis of these tools is often a department head reaching out to engineers and asking them to create a tool to solve some critical business problem. Given that a lot of these tools deal with sensitive data, or require working with multiple APIs or databases, engineers are best placed to create a vast majority of these tools.
Secondly, a lot of the work involved in building these internal tools is essential, yet repetitive. From incorporating access controls to ensuring the apps are secure to maintaining and updating software packages (assuming you’re using existing frameworks like React, Angular, Django) to integrating or building data integrations to building UI components.
With the average company using over 100 software applications, building and maintaining these tools can take anywhere from 20-40% of your overall engineering bandwidth. And given that engineers are often the most expensive resources in an organization, the costs of building and maintaining these tools quickly rack up.
Because building those internal tools is often tedious, considered thankless, and unexciting by software engineers, methods that can short-circuit the process of building internal tooling are in demand, particularly those that enhance developer productivity.
Over the last few years, we’ve seen a range of no-code and low-code tools arrive to help speed up development. No-code tools require no coding and are ideally placed to help non-developers build applications, whereas low-code tools help reduce the amount of code required to build applications and are ideal for developers to build applications quickly, while still giving them the ability to customize these applications. Since a lot of internal tools are still owned by the developer in the organization, we’ll limit the scope of this post to low-code platforms that enable a developer to become more productive.
The most striking feature of low-code tools is that they’re highly visual. Writing or editing code in an integrated development environment (IDE) is great, but it doesn’t necessarily help the developer to visualize what is happening.
Low-code platforms that are focused on internal tool development allow for a drag-and-drop experience where the developers (often backend engineers) don’t have to spend hours trying to optimize front-end elements and visualize what the final application looks like. All the changes you make to the application are visible in real-time and on the application itself.
These pre-built elements, along with other theming capabilities that the low-code frameworks come with, lead to two interesting benefits, among others.
Firstly, with these out-of-the-box elements, engineering bandwidth is conserved, which is very valuable. Add
itionally, engineers who aren’t the most skilled can also get started with these tools.
Secondly, because of a lot of out-of-the-box pre-built UI elements and theming capabilities, you can build applications with pretty good UX without any design help. This is useful since it’s hard to often find design help for internal-facing applications anyways.
The trade-off to keep in mind is that, depending upon the kind of low-code platform you use, the number of UI components might be restricted. So, in case you need some esoteric UI component, which is very specific to your use case, you might find those missing. However, many low-code platforms today allow you to create custom widgets. There are a variety of open-source low-code frameworks as well, which also allow you to contribute widgets.
A large part of application development in today’s world involves a lot of application management. Low-code tools are getting widespread adoption because, in a world where front-end applications are becoming more complex, they make things like hosting, deployment, authentication, and workflow functions much simpler.
As compared to custom code, where you have to spin up a server and set up CI/CD pipelines to deploy to your cluster, low-code takes care of this with the click of a button, saving developers time because they don’t have to spend time configuring and maintaining a custom deployment.
Similarly, authentication and authorization is a complex process to get right because there are different access controls to be thought of, invite flows need to be addressed, and onboarding and offboarding for team members need to be taken care of. Low-code products do the heavy lifting and have these features built in, allowing developers to define authentication and authorization in a much simpler manner.
An increase in the number of backend-as-a-service providers (Firebase and its alternatives) and their tight integration with low-code platforms are making the adoption of low-code platforms more seamless.
For example, Fyle, a fast-growing SaaS business that provides expense management solutions to their clients, used low-code to save 30% of their engineering bandwidth on support-related activities, giving them more time to focus on their main product. Fyle empowered its customer success team to self-serve requests. Fyle created an internal service request management system where about 30% of customers’ service requests could be handled immediately without having to be passed to engineering, saving valuable time and bandwidth for its engineering team while responding to customers much faster.
The challenges to keep in mind are that low-code platforms might not support the long tail of hosting providers. In addition, low-code platforms might not always support your niche authentication providers (for example, a system built on custom Postgres tables), and building that might require some effort.
An important extension of application management is version control. The ability to visualize a particular branch of an application, give detailed feedback or make changes on it, and then track it on Github or Gitlab makes the development cycle much faster.
While building Appsmith, we wanted to have built-in version control so that toggling between various versions of your internal applications becomes easier. This also makes it easier to fork application templates across the organization, leading to further time savings. This was a huge challenge in my previous organization.
You can switch a branch and automatically start making changes, as opposed to pulling code into your local machine and building the code before you can make changes. This makes the Git process better with a quicker feedback loop.
While developers often collaborate at the code level, non-developers’ (users of the applications) feedback is often at the design level. This is even more so the case for internal applications where often the business users don’t even know who built the application.
Real-time commenting (similar to Google Docs or Figma) facilitates collaboration between software engineering teams as well as with their business counterparts, who can now communicate directly, provide feedback, and collaborate with their engineering peers. This close collaboration empowers all parties, increases efficiency, and saves significant time while improving the overall quality of the software and ensuring that it realizes expectations.
In addition, non-engineers don’t need to familiarize themselves with a new tool like Github. Or go through a painful replication issue on JIRA involving a variety of screenshots or screen recordings. Sharing feedback can be done easily.
This is a key element in low-code platforms that helps improve the overall quality of the end prod
Source : infoq
Parsaland Trading Company with many activities in the fields of import and export, investment consulting, blockchain consulting, information technology and building construction