Having an internal tool built: when does custom beat off-the-shelf software?

Having an internal tool built is the logical step when your team spends more time working around software than on the work itself. Every organisation knows it: a standard package that does not quite fit, supplemented with spreadsheets, shared folders and separate lists that only their creator understands. That works until it no longer does. In this article we explain when custom software pays off, when you are better off sticking with standard software and how to build an internal tool without it becoming a large IT project.

What is an internal tool?

An internal tool is software your own team uses to do the work, tailored to your processes. Customers do not see it. Think of a planning overview for the shop floor, a system for assessing requests, a management environment for product data or a place where all the information about a project comes together.

The difference from standard software is the direction. With standard software you adapt your way of working to the package. With an internal tool the software adapts to your way of working.

When does it pay off to have an internal tool built?

It pays off to have an internal tool built if the process is characteristic of your organisation, occurs often and currently involves a lot of manual work or errors. A few signs that you are there:

• Spreadsheets as the backbone. A crucial process runs on an Excel file with tabs, formulas and colour codes that only a few people understand.
• Retyping between systems. The same data is entered into three packages because they do not talk to each other.
• Licences for features you do not use. You pay per user for an extensive package, while your team uses twenty percent of it and works around the rest.
• Knowledge in people's heads. The process works because a few experienced people know how to do it. If one of them drops out, it grinds to a halt.
• No overview. Managers ask for status updates by email and in meetings, because there is no place where it is simply visible.

When is it better to use standard software?

Standard software is the better choice if the process is not distinctive and the market already has a good package for it. Accounting, payroll, email and calendar are processes that work the same in almost every organisation. Building your own tool for them is rarely wise.

The trade-off usually lies somewhere in the middle. Often the best answer is: use the standard packages for what they are good at and build an internal tool for the part in between. That tool pulls data from your existing systems through integrations and adds what is missing.

What makes an internal tool good?

A good internal tool is fast, does a few things very well and connects to the systems you already have. Being extensive is not a quality. The tools that are used most are usually the tools that try to do the least.

Built around the daily task

Start with what people do every day. Which action occurs most often, and how fast can it be? A screen that makes the most important task possible in two clicks beats a screen with every possible option.

One source of data

An internal tool should not copy data, but use it where it already lives, or become the central place itself. Otherwise you end up with one more system that needs to be synchronised.

Roles and permissions

Not everyone needs to see or change everything. Define from the start who is allowed to do what. That prevents errors and makes it easier to roll the tool out more widely later.

Overview for those who steer

The people who do the work and the people who steer have different needs. A separate dashboard with the figures that matter prevents managers from searching through the work screens.

How do we build an internal tool?

We build an internal tool with the technology that suits the process, usually a web application with its own database and integrations with existing systems. We often build the front end in Next.js, and the database and logic on Supabase or Xano. For simpler applications, a well-configured Airtable environment can be enough.

More and more often we also include smart automation: documents that are read automatically, requests that are categorised automatically, texts that are prepared so an employee only needs to check them. Not as a goal in itself, but where it demonstrably makes the work faster or better.

We work in short steps. First the core that removes the most manual work, in use by the team. Then we expand based on what turns out to be needed in practice. That way you quickly have something usable and you build nothing that nobody uses.

What do the costs of an internal tool depend on?

The costs depend on the number of processes and screens, the number of integrations with other systems, the requirements for permissions and logging and the amount of data that needs to be migrated. A tool that supports one clearly defined process is a different project from a system that connects several departments.

Set that against what the current process costs: hours of manual work per week, errors that need to be fixed, licences you can cancel. That comparison usually makes it clear quickly whether custom software pays off.

How do you start?

Start with one process that takes a lot of time and is clearly defined. Map out who is involved, what the steps are and where it currently gets stuck. That is enough to decide whether an internal tool makes sense and what the first version looks like.

Want to discuss a process that could be better? Read more about application development and workflow automation, or get in touch.