Internal apps – the (often) neglected child of software development

Internal tools are custom software applications that are built for internal users in an organization. These applications mostly have CRUD functionality and are built by engineers for users like sales, support, finance, HR, engineering, and everyone in between. For example, here is an example of a tool we made to engage with our users using Mixpanel, Reply, and ActiveCampaign. Every company has internal tools to serve their specific needs and unique processes. As Michael Novati at Facebook writes while talking about a company communication dashboard that he was making, “We’ve learned that effective enterprise communication tools need to be engineered specifically for our employees because our employee base and business needs are very unique.”

Engineering Effort

Internal tools end up taking a decent amount of engineering time. Over time, these tools require more features, or additional tools get built (which is always the case). This also includes scale and keeping track of tools that are getting deprecated. This ends up becoming a nontrivial contributor to the engineering workload. 

The most common approach to building internal tools is using an open-source framework like React or Angular or Flutter. These are powerful frameworks, but require a lot of work to maintain. So, every new tool gets created from scratch. As Novati writes in the same blog post, “A problem we have at Facebook is that there are so many requests for custom internal tools (from engineers and non-engineers alike) that our internal tools engineers have trouble keeping up.” He then goes on to explain how Facebook went about creating reusable “widgets” or UI components so that people could make tools faster. Now, imagine doing this if you’re not from a company like Facebook with all of its technical people.

Internal tools, just like any other software, require collaboration and feedback between the builders and the users. This feedback often ends up across multiple places like Slack, email, Word docs. The internal user and the engineer together end up donning the hat of a product manager and they end up going back and forth, trying to spec out the application.

Internal tools often don’t have the best UX. There are many reasons for this. Some have to do with bandwidth, some relate to expertise. Also, it might be because internal tools might not get the priority that consumer-facing applications get. Plus, there i\s also hardly any design bandwidth assigned to these tools since most designers want to work on consumer-facing applications. 

As Hannah Mari-Kris, product manager at neo banking giant Monese, reflects, “The trickiest parts are usually when a particular view has to serve the needs of multiple teams.” This is because internal tools often deal with a lot of sensitive data and as the owner of the tool, you want to be very certain about who gets what kind of access, be it write or read access.  

Low code as an alternative?

Low code frameworks or platforms today provide a good alternative to building internal applications. 

These frameworks help reduce the amount of engineering effort required to build internal tools owing to a reusable and ever-increasing list of UI components, connectors or native integrations to data sources, collaborative features, and extensive documentation. 

And so the engineering team is building multiple custom applications on one platform itself without the hassle of managing multiple React or Angular applications.

Here’s how you can choose a good low code framework

Do check whether these platforms include developer-friendly features like a good code editor with linting capabilities, as well as version control and Git-sync, or having an IDE-like experience in the code editor with a native debugger. 

Collaboration is another important factor to consider. One of our most requested features has been a real-time commenting system akin to what you see in Figma, which can help relay feedback among developers as well as between the end-user teams, shortening the development cycle.

Do check if the low code framework comes with robust and granular access control functionalities since that in most cases becomes a deal breaker when evaluating these tools for use within enterprises.

Often the low code platform is replacing an open-source framework like React. Thankfully, there are open source low code frameworks today. Open Source low code frameworks give your team the power to control the speed of your development by reporting bugs and have a member of the community fix, it if not the maintainers. Or, if there’s a critical feature that you want that isn’t yet on the roadmap, you can just build it out or contribute to the main source code or contact the maintainers.  

Do check if the low code platform you’re going with has a self-hosted version. This becomes more important when you’re dealing with sensitive data and want to add an extra layer of security by hosting your applications on your own servers.

The post Internal apps – the (often) neglected child of software development appeared first on SD Times.

from SD Times https://ift.tt/3kyb5Z9