The Dilemma with Internal Tools and No Code App Builders: An Engineer's Perspective

“Can we build a tool to do X?”

‍

This might be a typical request coming to you as an engineer or developer working in any company that has some sort of operations. Building these tools inflicts pain on engineers because they leak into your regular engineering development cycles without any prior intimation or context. You might have already seen many of these tools built internally and catching dust because the team who built and used it don’t use them anymore.

‍

Throughout my career working with multiple medium to large enterprise organizations, one thing I’ve noticed is some teams have tons of internal tools built only for specific use cases. These internal tools live in the form of dashboards, forms, in-house ticketing systems, alerting tools, and web pages with buttons that do something that are dangerously ambiguous.

‍

Operation Tools Require Engineering Effort

From the time when we started building software products to solve end-user problems, we had to build a lot of internal software solutions to help run these end-user products. Some of them are treated like they’re part of the products and some of them are built to ease operations and manual work within the company.

‍

When humanity collectively decided software could solve most problems, Companies emerged left and right to solve most operationally intensive tasks using software. Quick commerce, mobility, ride-sharing, and anything and everything built as “Uber for X” started operating with software as its brains and operations as its hands and legs. This brought quite a lot of pain points in running these companies, your operations team fire-fight every day to fix delays in delivery, warehouse and logistic issues, or anything which involves things “not on the cloud”.

‍

These problems are wider than just companies that have heavy operations. Operations exist in a variety of different formats in most companies, from business operations, revenue operations, customer operations, or even the all-familiar “dev-ops” which most engineers are familiar with.

‍

The Rise of No-Code / Low-Code Tools

So, for every operational issue/pain point, there is someone in the company who knows how to solve it but is not skillful enough to build software solutions. Thus, a lot of these operations start eating engineering bandwidth to build tools to solve these problems. Now here lies the meat of the problem, for every business person who needs to solve an operations problem, there exists an engineer who has no time or clue about the problem.

‍

This is one of the scenarios where no-code/low-code tools and automations come into the picture. People who aren’t engineers can create decent tools to solve their problems, or for backend engineers who are afraid of writing HTML and CSS (obviously due to religious reasons). And VCs pumped tons of money into this market for companies like Retool, because the struggle to get engineers to build things that they have no context on is real (and making backend engineers write CSS caused riots within the team).

‍

Too many tools - Too many problems

With engineers grinding to build internal tools and operations swaying away with their fancy no-code tools, we all thought it would be happily ever after.

‍

‍

Too-many internal tools

Internal tools did solve a lot of problems, but too many of them created new problems. Not just with internal tools, automated workflows are also a different problem within the same space. Most of the companies have multiple automations and workflows built to solve specific operations issues. Often created using workflow builders like retool, n8n etc, and a few more of the kind written using cron jobs maintained by the engineering teams.

‍

When your operations team becomes heavily dependent on engineering, they lose the power to quickly experiment and identify issues on time, and often ends up looking at weekly or monthly reports showing enormous losses due to inefficiency.

‍

The context exists with only people involved in the project

Unlike the end-user product which is important for the company, these internal tools lack documentation, quality, and context and heavily rely on very few people who were directly involved with the project. When people with the context leave the organization, it becomes much harder to maintain or use these tools, often creating anxiety whenever you click the buttons on them because no one now knows what exactly the software does. Because, the sins committed while writing code or building software catch up much later, often too late.

‍

No accountability leads to liability

Operations without a process can cause crippling inefficiency in your company. As engineers, we know how hard it is to collaborate and ship products without processes in place. Some of these processes are baked into the tools we use, like Git and GitHub saving us a lot of time and effort. A well-thought-out process for operations makes businesses run like a well-oiled machine. When your operations are inefficient, your business becomes unreliable, and you give terrible experiences to your customers in multiple forms. From delays, unavailability, out-of-stock items, warehouse issues, and a lot more.

‍

What is a good operations process?

Notifying the right people at the right time to take action is just one aspect of the solution. Which some of the internal solutions for alerting are built for. But, making sure things get done on time, visibility of the issues so that it doesn’t get missed, and collaborations between multiple stakeholders are other aspects which required to run good operations.

‍

‍

Automations, your Retool app, workflow, or the alerts’ setup using CRONs running on your servers can solve most of the surface-level problems which have a predefined process to solve, but a huge part of business operations requires a human in the loop, whether to get notified, take action, or share visibility of the problem.

‍

A Breath of fresh air

Internal tools are unavoidable to run businesses today. There exists plenty of SaaS tools to build internal tools, and companies deploy a fortune to have engineering bandwidth to build a lot of these tools internally as well. The question remains, do your tools help you in creating better processes, accountability, and visibility? We had the same question in front of us.

‍

We built Locale from our frustration of handling multiple internal tools, dashboards, automations, countless cron jobs, and processes with no accountability in place. We built a tool with humans at the forefront when it comes to operations. Your team’s knowledge of operations, issues, solutions, and actions lives in a single place, a source of truth for your team. Instead of having tools and automations spread across multiple places, Locale unifies everything from monitoring, alerting, resolution, and closing the loop in one place.

‍

Locale directly connects with your database and SaaS your team uses so that your team can get started quickly. It’s not just another tool in your stack, it’s the entry point and exit point for your operations stack to identify and resolve issues with full visibility. Once you connect Locale to your database, you can quickly set up monitors using SQL to alert for critical issues. The possibilities are endless as long as you can write an SQL query to fetch issues to be monitored directly from your database.

‍

How our customers use Locale

‍

‍

Instead of endless notifications and multiple dashboards, teams get alerted only when they need to take action. Locale helps you to automate actions, or help your team quickly take action on issues when it is needed. Instead of adding another SaaS into the stack, Locale integrates directly into your team’s workflow. With 100+ integrations spanning across multiple channels, locale lives and breathes through your team’s communication channels to notify, log, and execute actions.

‍

Conclusion

In the complex landscape of internal tools and the rise of no-code app builders, engineers often find themselves entangled in requests to build tools without sufficient context. This has led to a proliferation of internal tools, ranging from dashboards to automated workflows, posing challenges of their own. While no-code solutions alleviate the burden on engineers, the sheer volume of tools has created a new set of problems – lack of documentation, accountability, and dependence on departing individuals for context.

‍

Locale emerges as a solution, unifying operations by serving as a source of truth for teams. By connecting with databases and SaaS tools, Locale consolidates monitoring, alerting, and resolution in one place, fostering accountability. Unlike traditional tools, Locale prioritizes human-centric operations, ensuring meaningful alerts and swift resolutions, all integrated seamlessly into the team's workflow. Instead of making redundant internal apps, Locale encourages a shift towards refining processes, saving time, reducing dependency, and facilitating effective operations.