What good internal tooling actually costs compared to the problem it solves

There's a conversation we have regularly. An organisation has an internal process that isn't working well. People are working around it, copying data between systems, passing around spreadsheets that nobody fully trusts anymore. Then someone asks: can you build a tool for that? And the next thing that happens is a discussion about budget.

The problem with that discussion is that the cost of the tool is visible, and the cost of the problem it would solve is not. Nobody has calculated what it costs when five people lose four hours a week to a process that fundamentally doesn't work. Nobody has tracked how often a customer receives something late because two systems don't talk to each other. Nobody has counted the decisions that were made on the wrong data.

At Livewall, we see this pattern repeatedly. And it almost always leads to the same mistake: organisations invest too late, or too little, in custom tooling because they never make the comparison honestly.

How to make the comparison honestly

The first step is straightforward: add up what the problem is already costing you. Not in vague terms like 'time lost' or 'frustration', but in concrete numbers. How many hours per week are wasted? What does that represent in staff cost? How often does it result in errors that affect people outside your team? What is the risk of a key person leaving because the work is unnecessarily hard?

That is the basis of the comparison. On the other side sits a well-built internal system or a custom web application. Something that removes the problem structurally, rather than working around it again and again.

What we've also learned at Livewall: with AI as a co-creator, development costs today are significantly lower than they were three years ago. A tool that once took six weeks can now be delivered in two to three weeks, at higher quality and with less technical debt. The comparison increasingly tips in favour of building.

Start small, but start

The second mistake we see: organisations wait for the perfect solution. They want to get everything right in one go, and so the project never starts. Or it becomes so large that nobody dares to begin.

Our approach is different. We start with a prototype that removes the biggest point of pain. Something you can build in a week and put to use immediately. Then you look at what it does, what it requires, and what the next step is. This is also how we work with clients like Zorg van de Zaak and Lefboom: not with a 100-page specification, but with something that works and grows.

The cost of a good internal tool is real. But it is also finite. The cost of the problem you don't solve just keeps running.