The Ultimate Guide to Building Internal Tools in 2023

What are Internal Tools?

Roughly speaking, any internally-facing software developed by a company to support internal operations can be called an internal tool. These range from CRUD interfaces that enable customer support to resolve support queries to bespoke technical tools, platforms, and libraries built to increase the productivity of other product teams. Internal tools securely connect to multiple data sources and APIs and have simple interfaces to allow non-tech team members to perform various types of CRUD (create, read, update, delete) operations needed in business workflows.

These tools help decrease the separation of data for companies, plug into a variety of services and applications, and ease the work of different departments through automation. As companies rapidly adopt digital technologies and frameworks, internal tools that bridge information silos and enable smooth scaling and growth are essential because they: 

• improve the team's productivity by avoiding repetitive tasks.

• provide quick and easy CRUD capabilities on databases.

• improve interactions between business verticals by connecting disparate information. 

• create easy and visual ways to understand business data and analytics.

• enable core business operations by automating complex backend workflows.

Examples of Internal Tools at Various Organizations 

From large corporations to small teams, internal tools can be found everywhere. For example, look at these custom solutions developed by different companies. 

• Airbnb built a reporting tool to simplify running experiments by hiding all the pitfalls and automating the heavy analytical lifting. 

• Facebook has a tool to enable staff to build their dashboards. 

• SaaS startup Fyle built an internal tool to reduce the support team’s dependence on engineering. 

• Oscar, a significant insurance provider, solved siloed systems to track and manage authorization requests with a utilization management app.

• Amazon CDK is an excellent example of an internal tool (which they’ve since open-sourced) to define your cloud application resources using familiar programming languages.

Building software is not mutually exclusive to purchasing a SaaS subscription; what we need today is frameworks that can help extend SaaS products, unlock the SaaS products’ data and make it usable across organizations. There are many types of internal tools such as customized CRM tools, dashboards, admin panels, ticketing systems, data entry and data mapping tools, content management systems, and more. These internal tools make it easy for teams to automate repetitive tasks, collaborate effectively, manage customer interactions, run campaigns,  measure performance, and manage all kinds of custom workflows and processes.

While many SaaS tools exist to solve these use cases, internal tools are critical when customization becomes key. Custom business requirements will always need custom solutions. Building a unique layer of functions on top of pre-existing tools makes it extremely easy for teams to get their jobs done. 

Should You Build or Buy? 

There is no one correct answer when it comes to building vs. buying; everything depends on your company's specific requirements and the use case at hand. For example, adding a new API or integration to a tool that has been purchased might not be easy. You might also want to consider if there will be vendor lock-ins; if users don’t take to the purchased SaaS products it will create more silos, and customizing an existing product could be complicated. Not just this, you could also end up being tied to the feature roadmap provided by the SaaS company. 

Building internal tools can be a tedious and thankless task. Developers and engineering teams often don’t have the bandwidth to take on every software requirement within the organization and are often looking for accessible alternatives and solutions. These alternatives would include frameworks and platforms that can help build internal tools without starting from scratch.

Some of these are entirely no-code builders, while others give you a choice to do more customization and have more control with coding. The latter are what are popularly known as low-code frameworks. There is no magic bullet here. It’s always best to evaluate what fits the needs of your workflow and organization. After all, there are many technical and organizational challenges to consider before you start building any internal tool. 

In the next sections, we will discuss the types of internal tools, the conundrum of building vs buying, things to consider while building internal tools and how to evaluate internal tool builders.

Types of Internal Tools

Any internally-facing software developed by a company to support its operations is an internal tool. The most common types of internal tools take the form of custom CRUD interfaces that help automate and streamline business processes and operations. For example, tools that help employees self serve customer support queries, manage campaigns, and analyze user behavior and product data.

Here’s a detailed list of the different types of internal tools used most often. 

Dashboards 

Dashboards help you make sense of your company's most essential data. They empower you to find solutions to your most pressing business concerns by combining data from multiple sources and presenting it in a customizable, visual format. Typically,  dashboards include statistic boxes, charts, and button groups and are used to perform CRUD operations on a company’s databases by non-tech users. A dashboard is a classic example of an internal tool built to visualize data from multiple sources.   A few examples of dashboards are 

• Management KPI Dashboards to track revenue, P&L, customer acquisition cost, etc.

• Business Analytics Dashboards for sales, growth, and marketing teams to identify top converting channels, track competition, and sales, visualize marketing budgets vs. ROI, etc. 

• Procurement Management Dashboards to visualize supply management data, and track supply, defect rates, and type of defects to optimize procurements. 

Inventory Management 

Inventory management software helps businesses track their item stock and maintain the optimal amounts without holding too much of any item. Usually, inventory management apps give an overview of stock items via tables, charts, and lists. These apps also include search features that provide users with an overview and the ability to go deeper and look up specific information about an item. Two examples of inventory management tools are:

• An Equipment Checkout System that offers a straightforward way to book and check assets by providing real-time visibility to reduce the loss of equipment and manage equipment inventory. Assets could include equipment used by employees, product stock, or any other company asset.

• Stock Management Tools that allow users to determine whether to order more stock, sell excess stock, and reduce wastage. 

Admin Panels 

Admin panels let users perform quick actions. For example, users can also manage various transactions, refunds, or push messages to large groups of customers via admin panels. Admin panels usually include input fields and modals to manage messages and transactions, and integrate with third-party connectors and SaaS services. Examples of Admin panels include: 

• Discount Campaigns Pushers or Message Pushers help users push discount campaigns to specific customers, track sales based on the campaign, and get insights into previous campaigns and success rates. Users could also use these apps to push messages to large groups of people across various channels. 

• Transaction Management Apps help users manage various transactions, such as processing refunds for canceled orders or processed replacements. 

Workflow Management Tools

Different organizations have different workflows that need custom tooling to manage and automate many day-to-day processes. Workflow management tools provide a way to audit, ensure compliance, and improve workflows in teams. Such tools usually include an upload field (depending on the type of application, the input could accept jpeg, PDFs, etc.), forms to capture information, radio button groups, approval forms, and role-based access controls for different types of users. Some examples include

• HR teams use Reimbursement Approval Apps to track employee reimbursements and manage payments.

• Leave, or Overtime Management Tools that track employee leaves and overtime under different categories. 

• Budget Request Tools that different departments in the organization can use to raise requests for various kinds of budgets. This can be rejected or approved by the management. 

CRM 

Customer relationship management (CRM) software is used to manage customer interactions. CRMs are usually built to track user and prospect contact details, identify qualified leads, track service requests, and manage marketing campaigns all in one spot. Most companies won’t build a CRM from scratch as it is a common, well-defined use case with many mature products available in the market. But many companies end up building internal tooling on top of their CRMs to handle custom business logic or to just connect its data to another tool. QR codes can also be integrated into CRM systems, allowing businesses to easily capture customer data by scanning the codes, enabling seamless tracking of offline interactions and bridging the gap between the physical and digital realms.

Depending on the type of the CRM tool, it would include charts, the ability to capture audio/video data, and connect to other SaaS products or other internal tools used for marketing or sales. CRMs can be categorized into operational CRMs and strategic CRMs. For example:

• Operational Sales CRMs would help users keep tabs on customer interactions, identify leads, forecast sales, etc., leaving room for employees to create more direct and impactful relationships with the customers. 

• Strategic CRMs help manage interactions (keeping track of all customer/user interactions) and channel management, which helps marketing teams decide on the best medium of communication with customers/users.

CMS  

Content Management Systems (CMS) enable teams to collaborate on projects involving media such as blog posts, videos, and image content for websites. CMS tools can also facilitate an approval process for content, collect feedback, and publish content to external outlets. Other CMS use cases include forums, membership sites, or content for training courses. Users can create, manage, modify, and publish content in a user-friendly interface with CMS apps. There are many different kinds of CMS software available, and these are usually highly customized to the organization's specific requirements. Some examples would include content publishing tools, content management, and approval apps. 

• Content Approval Apps help content teams sort out submissions from external writers/editors, provide feedback, and approve or reject content. 

• Edtech companies that deal with content and large volumes of information that need to be distributed require Content Management Tools that can help them present and distribute their content to their customers. 

Ticketing System

Ticketing software is widely used to manage long processes with multiple people and steps involved and to track customer service requests. Request tickets are stored alongside user information. With a ticketing system in place, it becomes easier to track open issues and reduce the time that employees spend waiting to get their issues resolved. IT and Customer Support teams tend to use ticketing systems for tracking and resolving issues and automating workflows. But no two ticketing software are the same; teams often need highly customizable ticketing software specific to their workflows. For example: 

• Customer Page Apps that store all information about the customer. These could also include the history of previously raised tickets to help customers and would typically include a list, tabs, and forms to update customer information.

• Workflow Automation Tools typically take care of the grunt work involved in customer support. Such tools need to process large amounts of data, automatically tag specific keywords, and notify support agents. 

Data Entry Tools 

Data entry tends to be a time-consuming manual process prone to errors and rework. Data entry tools allow users to collect and manage different documents, forms, and data. Data entry apps usually include forms, upload fields, and features to capture media (image, video, audio). Some examples of data entry tools are:

• Data Upload and Capture Apps can help users upload invoices, receipts, hr payrolls, forms, and other documents. The tool can capture this information and can be downloaded in different formats. 

• Document Automation and Processing tools that extract and process data from different sources such as PDFs, MS Word documents, emails, and other digital sources.

Customer Success Tools

As more SaaS companies hire customer success managers, their need for tooling grows too. Customer success teams need tools for things like:

• Bringing all customer data & communications together in one place

• Finding out which customers might be at risk of churn

• Finding out which customers might have potential for expansion & upsells

• Creating onboarding flows & educational messaging

These things can be done with a customer success platform like Gainsight, ChurnZero, or Planhat. The problem is, those existing solutions can be complex, and may not suit your exact internal needs & tech stack. Instead of buying, you can consider building an internal solution that brings together data like product usage, billing & revenue information, and customer communications that perfectly suits your needs.

Data Mapping Tools

Data mapping tools can capture, transform, and join data from multiple sources and purify/sanitize data to maintain consistent formatting. They are often used to bridge data between two different systems and provide analytics and summary data.  

Today, organizations acquire data from multiple and disparate sources. Data mapping is utilized to combine different data sources and develop automated data pipelines to make sense of dispersed data. An excellent example of internal data mapping tool is a data integration tool. Such a tool can control data integration activities such as data capture, purification, and storage in a standard and consistent format. This information can also be shared with end-users for analysis by the tool.

Most of these applications mentioned above exist as SaaS products that you can purchase, but it might not always be possible to customize them to suit your needs. Usually, companies choose to build tools mostly to connect pre-existing tools in the organization as a way to rectify the issue of data and information siloes. To build an internal tool or to buy one is a question that requires a fair evaluation.

In short, there are many things to consider before purchasing readily available tools. For example, you would need to think about where your data would reside and what integration options would be available to you; would you be able to customize the framework, to either have your internal apps look a certain way or extend the capacity of the tool you built beyond what the provider is offering? 

Build vs Buy 

At a time when there is an app or a SaaS product available for everything, why should anyone have to build an internal tool? Wouldn’t it be just easy to buy one? The answer is, that it depends. 

• Off-the-shelf solutions are not one-size-fits-all solutions. 

• If you buy too many individual products off-the-shelf that don’t talk to each other well, you may end up dealing with too many products and creating more data silos than you started with. 

• Customizing an existing business product is difficult. Many SaaS companies have decades of industry experience and offer power functionality, but they can become burdensome investments if they don’t suit your requirements perfectly. 

Apart from thinking about compatibilities and considering the ease of adding new APIs, and integrations, there are a few other things to consider before buying, such as vendor lock-ins and being dependent on someone else’s roadmap. Most companies build internal tools that are compatible with their existing SaaS tools. And these internal tools are built to extend the SaaS products and use their data in an easily-understandable, meaningful way. 

So when should you buy or build? 

It’s not really a binary choice between building vs. buying. It’s about choosing the right way that optimizes everyone’s time, especially engineering time. Non-customer-facing development improves efficiencies within the organization, but allocating the same resources to customer-facing development could potentially have a significantly greater RoI if internal tooling is handled by other bought software or potentially spending as little time as possible building internal tools (Non-customer-facing software). Companies should now evaluate the build vs buy decision through another additional dimension: building an internal tool quickly using low-code frameworks.  

Build vs Build Using a Low-code Platform vs Buy 

Whether you choose to build internal tools from scratch or use a low-code framework, there are some organizational, technical, as well as stakeholder challenges you should consider before diving in. The next chapter in this series dives deep into things to consider before you start building your internal tool. Read more related stories: 

• How neobank Monzo goes about building internal tools

• Why and how SaaS startup Fyle built an internal tool to reduce their support team’s dependence on engineering

Things to Consider Before Building Internal Tools

The process of building internal tools should follow the same principles as that of building a customer-facing tool. The idea behind building internal tools is to enable employees to do their work faster and more efficiently and to provide more transparency for teams and establish better workflows.  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. Having an easier way for end-users to give feedback and suggest feature changes to the tool is essential. The first step in thinking about building internal tools would be to identify the stakeholders and review the needs of the stakeholders. In this section, we will discuss a few steps involved in building internal tools. 

Identify Stakeholders Involved 

• Requestor: This is usually the manager of a team looking to improve the productivity outcomes of the team. 

• Product team (in some cases): Usually, a product team is involved in looking into the internal roadblocks and problems and works towards building a set of useful internal tools. 

• The design team (in some cases): A design team would look at the workflow and think about the user journeys. 

• Developer(s): The development team involved in making the internal tool.

• Compliance: The team would look into compliance issues and security vulnerabilities.

• QA: The engineers who would test the quality of the application

• End-user: The teams that would use the application as part of their work.

Depending on the size of an organization, there are dedicated teams working on building the internal products suite. However, smaller organizations usually have a set of developers who handle everything from customer-facing tools to internal-facing tools. In most cases, it’s just one person handling everything! 

What Should You Consider Before You Start Building an Internal Tool?

With internal tools, it's best to keep it simple and to the point. You don't want to spend time and energy only to realize that the application is a proverbial dinosaur. You want to use a tool that lets you build quickly and demonstrate to your team, take in feedback, iterate quickly, ship, and deploy. ‍

Am I building the right thing? 

It is always a good idea to rope in the key stakeholders so that you know you are building the right thing. Do I have enough clarity to get started? Try to get as close to properly specced out requirements as possible.‍

Adoptability‍

If no one uses your app, there's no point in the app. Involving users and key stakeholders right from the start would be a great way to ensure that what you build solves the users' problems. 

Solidifying a process‍

Ensure that the app you are building solidifies a preexisting process that works. If your tool is saddled with supporting a frequently-changing process, it's unlikely to work out in the long term. ‍

Decide between build or buy

If it’s not a highly custom requirement, or if you’re not solving a unique problem, it would be good to evaluate existing SaaS products. If the app requirements are highly custom and complicated, you might choose to either build from scratch (but this would require lots of resources). Alternatively, you could use a low code builder (ideally you don’t want it to have vendor lock-ins or be in a situation where you don’t own your code). But, building internal tools can be a tedious task, often deemed a thankless or unexciting job by devs, and for a good reason. This custom software with CRUD functionality comes at the expense of figuring out a bunch of technical considerations and staying up to date. 

Organizational Challenges of Building Internal Tools

• Budgets 

• Time (dependencies between front end and back end teams) 

• Resources (developer time is expensive)

• Iterations to get to the final/usable version

• Onboarding users/Adoption

• Frequent changes in process or workflow lead to multiple iterations requests

Technical Challenges While Building Internal Tools

• Figuring out authentication

• Configuring or creating API connectors

• Struggling with UI libraries

• Keep track of upgrades of open-source frameworks

• Staying up to date with React Native documentation

• Managing user accounts and roles 

• Building a secure app (not exposing database/API credentials, preventing SQL injection)

and many more! Today, there are many frameworks that help you build internal tools without starting from scratch. Some of these are entirely no-code builders, while others give you a choice to do more customization and have more control with coding, and these are what are popularly known as low-code frameworks. Here’s a blog post from neobank Monzo around how they build such tools. However, there is no magic bullet. It’s best to evaluate what fits the needs of your workflow and organization.

Evaluating Internal Tool Builders

There are many ways to go about building an internal tool. In the previous sections, we discussed the options of building vs buying internal tools. Of course, there are a couple of ways to go about building internal tools. One would be to build everything from scratch, this would mean building the backend and the frontend (UI) from the basics. The other way would be to do it with a builder (either no-code or low-code) which takes care of the frontend and have methods to add data sources. 

However, it’s important to note that not all builders are created the same. With no-code builders, there is no code involved but customizing the frontend might be limited. With low-code builders, you will likely have the flexibility to customize the look and feel of your applications and the functionality of your applications, but you will have to consider other parameters such as ownership of code, extendability of the builder, and application among many others. In this section, we will dig a little deeper into evaluating builders from critical perspectives that go beyond cost-effectiveness and ease of use. Off the bat, here are a few things to first consider when building internal tools: 

• ‍Integration Options: Where does your data reside, and what integration options do you have? 

• Customization: You should evaluate the degree of control you will be able to have with the platform in case you need to customize your apps to look a certain way. 

• Learning Curve: You want to be able to build something useful with something you or your teammates already know. Run away from tools that demand learning some obscure esoteric language. 

• Robustness: You and your teammates should be able to easily make changes to the tool, use version control like git, and document your implementation decisions.

• Support: It should be easy for you to get support to quickly and effectively answer your "how-to" questions. 

• Costs: The best-case scenario is always free, but it's good to consider what money can get you. Pricing should be evaluated regarding whether it provides you with better support. When evaluating pricing, check whether it is user-based or usage-based. 

• Security and Compliance: A usual first step is checking for compliance with things like SOC2, GDPR, etc. You could also evaluate whether your users' data will be secure and private, what kind of telemetry you are okay with, etc. Of course, this only applies if you’re using a cloud-hosted provider. 

• Permissions and Access Control: Always evaluate whether you will need special access to databases or APIs to build the tool. Once your tool is ready, will you need special layers of permissions for the users? (for example, "QA should have read/write access, and everyone else should have read-only access") Will the sign-on be seamless? (Your tool will be unsuccessful if you expect your teammates to create new accounts to use it.)

• Maintainability: Will your app break constantly? Is the tool you're using being maintained and updated? Do they offer version control? Place particular importance on the documentation and how easy it is to find information when you need it.