Your business does not need more software. It needs less chaos.

Sales lose track of enquiries, so the business buys a CRM. Projects slip, so a task tool is added. Invoicing stalls, so another application joins the stack. Every one of those decisions was sensible.

A year later you ask how many open jobs the company has and what margin they carry. The answer takes two days rather than a minute. The data exists, it just sits in five systems that cannot see one another, and somebody has to stitch it together by hand.

This is not a software problem, it is a problem with the shape of the business. To be clear from the outset: this article does not argue that a custom system is the answer. In most cases it is not. The goal is not fewer applications at any price, it is a lower total cost of ownership.

The typical stack nobody designed

Try listing the software your company uses. Most owners stop somewhere between six and ten: CRM, accounting or ERP, email, Excel, WhatsApp, Notion, invoicing, time and attendance.

The real number is usually higher. According to the Zylo 2025 SaaS Management Index, companies with 1 to 500 employees run 152 applications on average. Zylo puts the average company at 305, while the MuleSoft Connectivity Benchmark Report 2025 reports 897 for large organisations. The figures do not contradict each other, they simply measure different samples. One thing holds across all of them: the number of tools a company actually pays for is higher than the number its leadership can recall.

Every system can be good. The problem lives between them.

The CRM does its job well and so does the accounting system. The trouble starts when the same order has to exist in both and nobody has said which one is the source of truth.

A single source of truth means that for every important piece of data there is one place holding the official version, and everything else only reads from it. Without that, a customer has three addresses, an order has two statuses and the report shows a third number. Nobody is lying, everybody is right within their own system.

According to MuleSoft, only 29% of those 897 applications are connected, and 90% of IT leaders say data silos are causing business problems. MuleSoft reported the same 29% in its 2023 edition. In two years the figure has not moved.

SaaS sprawl and shadow IT

SaaS sprawl is the uncontrolled growth in the number of subscribed cloud tools, to the point where nobody holds a complete list of what is being paid for, who uses it and what data sits inside it. Shadow IT is its close relative: tools that teams acquire without the knowledge of the people accountable for technology and data. A spreadsheet in a personal account, a chat tool the sales team introduced on its own, or an AI assistant holding customer data.

Gartner reports that 74% of technology purchases are at least partly funded outside IT, and that 41% of employees are business technologists, people who build technology capability outside the IT function. At its London summit in September 2025, Gartner predicted that “75% of employees will acquire, modify or create technology outside IT’s visibility”. That is a forecast, not a measured state. Zylo sees the same thing in the money: its 2026 index puts 81% of SaaS spend under the control of business units and only 15% under IT. And 77% of IT leaders have found AI applications inside their own company that they did not know about.

Shadow IT is not indiscipline, it is a symptom. People route around the official path when the official path is slow. If approving a thirty euro tool takes six weeks, they will buy it themselves. The answer is not a ban, it is faster approval.

The hidden costs the subscription line does not show

The total cost of ownership method was popularised by the Gartner Group in 1987. CIPS defines it as an estimate of end-to-end costs, including the processes that add no value. With software it comes down to five items, only the first of which appears in your budget.

• Unused subscriptions. The Zylo 2026 SaaS Management Index finds that 36% of licences go unused on average. The median SaaS spend per employee is $9,455 a year.
• Integration overhead. MuleSoft reports that 39% of IT team time goes on building custom integrations. In the 2023 edition, companies spent an average of $4.7 million a year on them.
• Training, administration and duplicated data. Every tool has its own login, its own roles and its own onboarding. The same customer held in three systems means three places for an error to appear.
• Switching cost. What it takes to leave a vendor: export, migration, retraining, rewriting the integrations. It grows the longer a tool is in use, which is why even a weak tool stays for years.
• Lost visibility. The Flexera 2025 State of ITAM Report shows the share of organisations with full visibility of their own technology stack falling from 47% to 43%.

These figures come from international surveys, mostly of larger companies. Treat them as a direction of travel rather than a prediction: the subscription invoice is usually the smallest item on the list.

Why there is a person acting as an API in your company

An API is the interface through which two programs exchange data automatically in an agreed format. When that interface is missing, a company unwittingly builds one out of a person. An order arrives by email, somebody retypes it into the CRM, somebody else copies it into the planning spreadsheet, the date goes from the spreadsheet to the engineer over WhatsApp, the engineer reports the job done, somebody writes that back and raises the invoice. Four of those seven steps are not work, they are just the same information being moved.

That person is the integration. Only slower, prone to mistakes, without a log and impossible to scale. And unlike a licence, their cost never appears in the budget, even though it can be calculated.

The Cost of Friction framework, which I set out in the article on when a good internal system pays for itself sooner than a new hire, is deliberately simple: time × frequency × number of people × cost.

A worked example, put your own inputs in. Moving one order takes 4 minutes, it happens 40 times a week and 3 people are involved. That is 8 hours a week, or 360 hours a year across 45 working weeks. Nine working weeks of one person’s time spent retyping data from one window into another. Multiply that by your internal rate and you have your first number.

The second number is the error rate. In a 2021 Asana survey reported by CIO Dive, workers switch between 13 applications 30 times a day and more than a quarter say that actions and messages slip past them as a result. It is an older, secondary source, so treat it as an indication rather than proof.

The decision grid: what to use when

For every point of friction there are four possible answers. The first one is right most often.

1. Off-the-shelf software

If the process is standard and is not the source of your competitive advantage, buy a ready-made tool. Invoicing, payroll, accounting, helpdesk. If it covers eighty per cent of the need and the remainder is not what your customer pays you for, adapt the process to the tool. Companies do this far too rarely.

2. Integration

If two systems both work well and simply do not talk to each other, the answer is a connection, not a third system. Look for a native connector from the vendor first and only then reach for an integration platform. Watch the integration overhead: every integration can break on an update, so connect few things and connect them properly.

3. Automation

If the process is stable, repeats and its logic can be written down as rules, automate it. But only once you have simplified it. Otherwise what I wrote in the article on why AI will not fix a broken process applies: you have only made the wrong thing cheaper and faster.

4. A custom system

Custom software makes sense in a narrow set of cases: when the process is a source of competitive advantage and no ready-made tool covers it without distorting it; when licence costs rise with headcount faster than the cost of running your own solution; or when you need a single source of truth for an area that no tool on the market fits.

Knowing when it does not make sense matters just as much. A custom system has a total cost of ownership too: development is only the beginning, then come maintenance, security and dependence on whoever knows how to change it. If you are not confident you will still be running it in five years, do not build it. The best audit outcome is often that nothing gets built, three tools get cancelled and one finally gets configured properly.

How to run a technology and process audit

In a smaller company this is not a six month project, it is two to four weeks of conversations and one spreadsheet.

1. Build the tool list from the money, not from memory. Go through twelve months of company card statements and expense claims. Zylo reports that spend going through expense reports rose 267% year on year. Anyone looking only at central invoices is seeing part of the picture.
2. Map five to eight key processes. From first contact to paid invoice. For every step, write down who does it and in which system.
3. Mark the retyping points. Everywhere a person carries data between systems. These are your human APIs, so run them through Cost of Friction.
4. Name the single source of truth. For the customer, the order, the project and the invoice, name one owning system and let the others do nothing but read from it. Most arguments about numbers are not arguments about facts, they are arguments about which export counts.
5. Find the duplicates. Zylo reports that generative AI has entered the list of most redundant functions for the first time: companies keep seven such applications running at once on average.
6. Keep the order: Remove, Simplify, Automate, Augment. First remove the steps that do not need to exist, then simplify what is left, only then automate, and add AI last. Start at the wrong end and you cement the chaos in place.
7. Set a rule for adopting a new tool. One page: who owns it, what data will live in it, how it connects and how you get out of it.

A worked example: 28 people, seven systems

Before. A hypothetical service company, not a specific client. It has 28 employees, 12 of them field engineers. Enquiries arrive by email, quotes go into the CRM, the schedule into a shared spreadsheet, the engineers are managed over WhatsApp, documentation sits in Notion, invoices in the accounting system and time and attendance in a tool of its own. An order exists in four places in four versions, the month end close takes two days and the margin on a job is only known six weeks later, when nothing can be done about it.

The audit. The company pays for three tools nobody uses, and two more do the same job as each other. The most expensive spot, though, is none of them: it is the retyping of a job between the CRM, the spreadsheet and the accounting system.

After. The order gets one owner, the CRM the company already has. The planning spreadsheet disappears, because the same function sits in a module the company has been paying for and not using for years. The accounting system is connected with an off-the-shelf connector. WhatsApp stays, but it stops being the place where the official status of a job is set. Exactly one thing is built: a mobile app for the engineers that records their job sheet straight into the CRM, because no ready-made tool fitted the work in the field.

Four of the five changes needed no code at all: dropping the spreadsheet, configuring a module already paid for, an off-the-shelf connector and one rule. Development came fifth and was the smallest part of the job. That is what consolidation is about: not a large custom system, but the ability to spot the single piece worth building. I took the same logic further in the article on building a company without an admin army.

So the question is not whether you need another tool or a custom system. The question is where the friction sits in your process and what it costs. That cannot be guessed from behind a desk, it can only be measured.

Key takeaways

• Count your software from bank statements and expense claims, not from memory.
• Find the places where a person carries data between systems and run them through Cost of Friction: time × frequency × number of people × cost. That number sets the order in which you fix things.
• For every key object, name one system as the source of truth. It costs neither a licence nor a line of code, only a decision.
• Keep the order: Remove, Simplify, Automate, Augment. Automating an unfixed process only gives you faster chaos.
• Optimise for total cost of ownership, not for the number of applications. Off-the-shelf software is the right answer most of the time. Build your own only where the process is your competitive advantage and you will be running it for years.