Internal tools accumulate the same way business software does: one at a time, each solving a real problem, none of them planned. A small app to track something. A form someone built. A script that runs weekly and only one person knows about.
Individually they are sensible. Collectively they become an unmapped layer of the business that nobody owns, nobody documents, and everybody depends on.
The question is not whether to build internal tools. Most operations need some. It is which ones justify existing, and that turns out to be a smaller set than the request list suggests.
The request is usually not the requirement
When someone asks for an internal tool, they are describing a solution. The useful move is to work backwards to the problem, because the stated solution is frequently the wrong shape.
"We need a tool to track which orders are pending approval" might mean:
- Approvals take too long → a routing problem
- Nobody knows what is pending → a visibility problem
- Approvals happen in chat and get lost → a record problem
- Too many things need approval → a policy problem
Only two of those are solved by a tool. The fourth is solved by changing the policy, and building software for it makes an unnecessary process permanent and harder to remove later.
Ask what happens if the tool is not built. If the answer is "we keep doing it manually", you have a candidate. If it is "we would have to fix the underlying process", the tool is a way of avoiding that fix.
Three tests before building anything
Does the data already exist somewhere? Most internal tool requests are visibility problems, not capability problems. The information exists — it is in the operations system, or in an export — but it is not where the person needs it. Surfacing existing data is much cheaper than building a new place to enter it.
Will it need maintaining? Anything that reads from another system breaks when that system changes. Anything with a login needs access management. Anything holding data needs backup. A tool nobody maintains becomes a tool nobody trusts, and then a tool that quietly reports stale figures.
Who owns it when the author leaves? The most common failure mode for internal tools. Someone builds it, it becomes load-bearing, they move on, and nobody can change or fix it. If a tool cannot survive its author leaving, it is a liability wearing the costume of an asset.
What is usually worth building
Things that surface existing data in a decision-shaped way. A screen showing exactly what a specific role needs to act on. Cheap, low-risk, high-value — because the underlying record already exists and stays authoritative.
Things that remove duplicate entry. If staff enter the same information in two places, closing that is worth real effort. It removes a category of error rather than a task.
Things that enforce a rule that matters. Preventing an order that breaches credit limit, or a discount beyond authority. Where the cost of the mistake is high and the rule is unambiguous, encoding it pays.
What is usually not
A better view of a bad process. Making a slow approval chain visible does not shorten it. Fix the chain.
Something one person wants. A tool used by one person, requested by that person, maintained by that person, is a personal script. That is fine — call it that, and do not treat it as infrastructure the business depends on.
Replicating something you already pay for. Common with reporting: teams build a custom report because the existing system's export is inconvenient, and now maintain a parallel version that will eventually disagree with the source.
Anything you cannot staff. If nobody will own it in six months, the honest answer is not to build it.
The hidden cost is fragmentation
Each internal tool adds a place where truth can live. Two tools reporting the same number will eventually disagree, and when they do, the business gains a new question — which one is right — on top of the original one.
This is the same failure as the accumulated software stack, at smaller scale: many sources of truth, reconciled by people. The structural answer is that internal tools should read from the operational record rather than maintain their own copy of it. That is the architecture argument in what a business operating system actually is.
A tool that reads is cheap and safe. A tool that stores is a second database with all the obligations of the first.
Low-code and the two-year problem
Low-code platforms have made building internal tools genuinely accessible, and for narrow, stable, well-understood needs they are frequently the right answer.
The failure mode is specific and worth naming: after two years, an organisation has thirty small automations and apps built by people who have moved on, with no documentation, no test coverage, and unclear ownership. Each was cheap. The aggregate is a maintenance obligation nobody scoped.
If you use them, keep a register: what exists, who owns it, what it reads from, and what breaks if it stops. That single document prevents most of the pain.
What we have seen
Across the ten systems we have delivered, the recurring pattern is that businesses arrive with a list of tools they believe they need, and the list shrinks substantially once we watch the actual work.
Most requests turn out to be one of three things: information that exists but is in the wrong place, duplicate entry that a shared record removes, or a process step that should not exist. Genuinely novel capability is the smallest category.
This is why our first phase documents the operation as performed rather than as described — including the tools people have quietly built for themselves. Those homemade tools are the most honest specification available, because each one marks a place where the official system failed someone enough that they built around it. The method is in how Truffaire builds software.
The related judgement — whether to configure, buy, or build at all — is in off-the-shelf or custom.
Frequently asked questions
Should we build internal tools ourselves or hire?
If it is small, stable and one team uses it, building internally is often right — provided ownership is assigned rather than assumed. Anything load-bearing across the business deserves the same scrutiny as bought software, including who maintains it in two years.
How do we stop internal tools proliferating?
Keep a register and require an owner before anything is built. Most proliferation happens because there is no cost to creating one and no record that it exists.
Is it worth replacing our internal tools with one system?
Only where they overlap or disagree. Tools doing genuinely distinct jobs, with clear owners, that read from the operational record, are fine as they are. Consolidation for its own sake is expensive.
What about tools built by staff who have left?
Audit them: what it does, what it reads, who depends on it. Then either assign an owner or retire it. The worst state is a tool everyone uses and nobody maintains, because it will fail eventually and nobody will know why.
Can AI help build internal tools faster?
It can make building faster, which makes the discipline above more important rather than less. The constraint on internal tools was never build speed — it is maintenance and ownership, and those do not get cheaper.
Where to start
List every internal tool that currently exists — including spreadsheets with formulas, scripts, and forms. For each, record who owns it, who depends on it, and what it reads from.
That list usually answers the question. Tools with no owner and real dependency are your risk. Tools that duplicate the operational record are your future disagreement. Tools that surface existing data cleanly are the ones worth keeping and extending.
Then, for any new request, work backwards from the stated solution to the actual problem — and check whether the honest answer is a change to the process rather than software.
If you want a read on which of your tools are load-bearing, get in touch.