Appsmith, an Open Source Low-Code Framework to Build Internal Apps

There’s a growth lever that isn’t spoken about enough. It sits at the intersection of engineering and pretty much every other department in a company. And it’s internal tools.

Yea, we’ve all built those. Those custom software often with CRUD functionality that come in the form of dashboards, admin panels, workflow automation. And if you’re a backend engineer (and, of course, you are), I can see the color drain out of your face. Those endless nights wrangling through UI libraries, figuring out authentication, configuring and (gasp) creating API connectors because your company now uses 100+ software applications, as well as going through the latest React Native documentation.

And 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.

Below are some of my learnings around building great internal tools that developers and engineering leaders should keep in mind.

Awareness of the Downstream Challenges of the Framework You’re Adopting 

If you’re building internal tools, you have many options. However, more often than not, you invariably end up embracing a framework like React, and at first, it seems like a great idea. However, very quickly you might realize that this rabbit hole goes deep. It’s important to be self-aware of the overheads.

First, you also want to think about role-based and granular access control from day one. You don’t want everyone to have access to the “god-mode” features. So you’ll often need to decide between making an extensive single application with a complex and flexible permission model or smaller, more straightforward applications.

You also want to be meticulous about software upgrades, more so because your team might only want specific package upgrades lest they break the application, which might be running a business-critical operation like your entire support and refund process. Some libraries will solve some problems but create new ones.

It might be a good idea to think about low-code solutions as an alternative to admin panel frameworks from Django, Laravel, React, Angular or, as I like to call them, the usual suspects, mainly because the low-code frameworks end up taking care of a lot of the overheads. More on that below.

How to Convince Software Engineers to Work on Internal Tools

It’s important to get engineers to buy into the idea of developing these tools. Talking about the “why” first and emphasizing the impact are critical because, at the face of it, these tools aren’t sexy, even though they’re business-critical. Hypothesizing the impact can help engineers understand the end goal. For example, telling your team that via a tool they can save X monthly hours of time for the company (or Y% of their own time), eventually leading to $$ savings or revenue increase for the company, are all great ways.

But just because it’s impactful doesn’t mean it’s fun. This is because, as anyone who has built these tools knows, there’s a lot of repetitive grunt work involved. Eliminating repetition through automation becomes another important aspect to take care of while thinking through these tools. Using low-code software so engineers can focus more on logic and create more complex applications is a great way to convince engineers to work on these tools. Most of these software share common attributes like having prebuilt UI components, native integrations with a variety of data sources, inbuilt authentication, role-based access control functionality and can often be both self-hosted or used on the cloud.

Embrace Open Source

One of the reasons I started Appsmith, an open source framework to build internal tools, was because after seeing and using a lot of these app-building frameworks, I noticed most of the low-code products were proprietary in nature and, secondly, these systems quickly racked up a bill because the tools often had a “user-based” pricing regardless of whether this was a developer or end user.

Whether or not you embrace a low-code framework, you definitely want to embrace open source.

First, it helps you to prevent vendor lock-in and not be dependent on a company’s future.

One of the reasons I started Appsmith, an open source framework to build internal tools, was because I noticed most of these low-code products were proprietary in nature, and secondly, these systems quickly racked up a bill.

Second, you have the power to contribute critical features or integrations that matter to you. For example, you may be working with a database that isn’t supported or there’s a bug that doesn’t seem to be a top priority for the product/framework. If the product is open source, you’ll be able to contribute a fix and not let project timelines of the maintainers or the company slow you down. With proprietary frameworks, you are beholden to a company’s priorities.

Finally, with open source, you have more control over how you build, deploy and secure your data. Since all the code is available in the public domain, you can also perform security audits on the codebase to ensure that it meets your InfoSec requirements. As with any open source project, it’s important to choose those that are feature-rich, have good support and have a growing community.

Project Management Should Include Collaboration with Nontechnical Users

Your internal tools will have a significant number of nontechnical users and collaboration is going to be an important part of the development cycle.

Collaboration spans two major buckets: collaboration around development and requirements gathering and collaboration around feedback. While engineering teams live on tools like Jira and Github, these channels aren’t very inclusive ways of gathering feedback from non-technical users since those users now have to learn a new tool.

I’ve been fascinated by what Figma did with real-time commenting and what Netlify is doing with deployed previews. In fact, at Appsmith, we recently rolled out real-time commenting and will soon release real-time editing, in addition to Gitsync, so that developers can do version control as well as get feedback from internal non-technical users. But if you’re using other channels, just keep the end user in mind and make it easy for them to give feedback. Stick to the channel that doesn’t require the users to learn a new tool. (Jira, I am looking at you specifically!)

And Finally, Onboarding Users of Internal Tools 

Just like external products, internal tools need to be used and loved by users. In a lot of these cases, the users are non-technical folks.

Make sure that every internal tool has ownership clarity. This can further be split into feature-level and engineering-level ownership. Ideally, someone should be tracking efficiency gains and thinking of ongoing process improvements. This becomes more critical as you keep adding to your tool repository.

This means thinking about internal tools the way you think about customer-facing applications. This means tool tips, documentation, troubleshooting, having an easier way for end users to give feedback and suggest feature changes to the tool.

Finally, it is good practice to have an ongoing review of the tool and the ability to provide improvement suggestions both on an ongoing basis as well as at quarterly check-ins.

Internal tools are often the ignored workhorses that keep your business running. Treat them with care, and they’ll help accelerate your business.