Low-Code Tools Optimize Engineering Time for Internal Applications

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. 

Visual, Real-Time, and On the App

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. Additionally, 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. 

Application Management and Deployments Are Faster 

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. 

Better Type of Version Control and Feedback Process for Developers

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. 

Real-Time Collaboration and Feedback Loops Can Become More Inclusive

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 product and results in much higher (internal) customer satisfaction, and is more productive since the feedback loop is an integral part of development.

Embrace Open Source

Regardless of which low-code framework or product you go with, you definitely want to embrace one that is open source. Why? The most common reason that proponents of open source will say is to prevent vendor lock-in and not be dependent on a company’s future. 

The biggest reason for us to make Appsmith open source was because we believe that these internal tools are a critical part of an organization’s tech stack, and as such, shouldn’t be caught up in vendor lock-in. 

However, there are other really important reasons:

You have the power to contribute critical features or integrations that matter to you. Every company is unique and the applications that they build for their internal business operations are often highly customized. This dependency on customization increases with scale, so having the ability to build out new features even if they aren’t on the vendor’s immediate roadmap is a massive advantage from a productivity standpoint. With proprietary frameworks, you are beholden to a vendor’s priorities. This is where community becomes so important and so 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. At Appsmith, we see community members contributing new UI components (like this awesome 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. 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. Since the code is public, performing security audits on the codebase to ensure that it meets your infosec requirements becomes easy. As with any open-source project, it’s important to choose those that are feature-rich, have good support, and have a growing community.