• 131
• 255
• 14

What to think about adopting a no-code/low-code platform for internal apps

by bernt & torsten

If you are building apps for internal use, you will end up embracing a framework like Angular, React or something else; if you taken that path very quickly, you might realize that this coding and timeframes of delivery takes more time than expected. As a manager you need to be self-aware of the overheads.

In building an internal app, you also want to think about role-based and granular access control. You do not want everyone to access all the features. So you often need to decide between making a single extensive application with a complex and flexible permission model or smaller, more straightforward applications.

You also want to plan for software upgrades because your team might only want specific package upgrades; they break the application, which might be running a business-critical operation like your full support and refund process.

It might be a good idea to think about low-code solutions as an alternative, mainly because the low-code frameworks take care of a lot of the overheads.

List of low-code/no-code framework

How to Convince Software Engineers to Work on Internal Apps

Software engineers need to buy into developing internal apps, and talking about the “why” first and emphasizing the impact are critical to understanding the end goal. For example, telling your team that via an internal app, 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.

As anyone who has built internal apps knows, there’s a lot of repetitive work involved to eliminate repetition through automation. Using a low-code framework, engineers can focus more on logic and create more complex applications to convince software engineers to work on these tools.

Embrace Open Source

we have started using  Appsmith, an open source low-code/no-code framework to build web apps. We chose Appsmith after trying out a few other proprietary low-code products. The proprietary was not free as these low-code/no-code frameworks often had “user-based” pricing regardless of whether this was a developer or end-user.

Using Open Source will prevent vendor lock-in and not be dependent on a company’s future.

With choosing a open-source low-code/no-code framework, 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 low-code/no-code framework.

If the product is open-source, you will be able to contribute a fix and not let the project timelines of the maintainers or the company slow you down. With proprietary frameworks, you are accountable to a company’s priorities.

With open source, you have more control over building, deploying and securing 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.

Rule of thumb

It is essential to choose an open-source platform that is feature-rich, have good support and has a growing community.

Project Management Should Include Collaboration with Nontechnical Users

Building with an low-code/no-code framework will have many non-technical users, and collaboration will be an essential part of the development cycle.

There are two types of collaboration: collaboration around development and requirements gathering and collaboration around feedback. While Dev teams live on tools like Github, these channels aren’t very inclusive in gathering feedback from non-technical users since those users now have to learn a new tool.

You need to select a no-code/low-code platform that supports real-time commenting and Gitsync so that developers can do version control and get feedback from internal non-technical users.

Onboarding Users of No-Code/Low-Code Apps

When launching a new Apps make sure that every app has ownership clarity. This can further be split into feature-level and development-level ownership. Ideally, someone should track efficiency gains of an app and think of ongoing process improvements. This becomes more critical as you keep adding to your app repository.

You need to thinking about adding tooltips, documentation, troubleshooting, and having an easier way for end-users to give feedback and suggest feature changes to the app.

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