Making Tech Stacks Make Sense

How to solve SaaS bloat without ripping out all of your platforms, or spending a fortune on even more SaaS products. Whether you run 30 systems or 957.

TL;DR

• Most organisations, from £20m businesses to government departments and large enterprises, are running more software than they realise, and most of it doesn’t talk to each other.
• That creates a ‘Fragmentation Tax’: not just subscriptions, but manual workarounds, arguments over whose numbers are right, slow decisions, and AI that can only be bolted on because the data is everywhere.
• The usual fixes come from the SaaS era: connect everything, centralise everything, or buy a bigger platform.
• I think there’s a better way: keep the systems that are useful, build a layer that makes them agree, then let AI sit on top so people can ask questions and get straight answers.

A tale of 957 systems

During the booming SaaS era, from the late 2000s to 2022, businesses of all sizes accumulated software until their tech stack looked less like a stack and more like a heap.

At the seams of these systems is an opaque but very real tax, and the bill is now due. Leaders are noticing the cost and asking whether they still need to pay it. They’re also finding that the transformational AI gains they were promised are out of reach, because their software barely talks to itself. So AI gets bolted on, usually as a chatbot, rather than woven through the organisation. Fragmentation is an old problem with old, SaaS-era solutions. I’d like to argue that the AI era opens up a genuinely new way through it.

Everywhere I look, organisations are trying to solve this. HMRC has just agreed up to £2.4bn to bring in Salesforce to tackle scores of fragmented systems. Police Scotland, SEPA and Scottish Enterprise have all put out tenders aimed at the same problem. And it’s not just the public sector.

Salesforce and MuleSoft’s 2026 Connectivity Benchmark Report, compiled with Deloitte Digital, surveyed 1,050 IT leaders at large enterprises. The average organisation now runs 957 applications, only 27% of them are connected, and 64% of IT leaders are worried about meeting their near-term AI goals as a result.

You don’t need 957 systems to feel this, though. A typical £20–50m business I work with runs around 30 software products: an accounting package, a CRM, an industry-specific operations system, Microsoft 365, and a long tail of spreadsheets and other tools. I’ve seen the same pattern in financial services firms, pharma companies, energy companies and industrial businesses. And the tax is arguably worse for smaller organisations, because there’s no data team to absorb it. It lands on a finance manager, an operations specialist, and a handful of overstretched people who know how the numbers really get made.

The tax is arguably worse for smaller organisations, because there’s no data team to absorb it.

Try counting the software in your own organisation. I suspect the number will surprise you.

The Fragmentation Tax

In theory, having lots of software products isn’t a problem. In practice, it usually is.

Most businesses accumulated their products with good intentions. A new HR system was needed, a good deal was had on a CRM, a spreadsheet got too unwieldy so a product was bought, an audit flagged the need for another, a new senior leader brought their own preference. Then the vendors themselves expanded, embedding their systems so deeply across the organisation that it would take a miracle, or a lot of money, to unwind them. Years tick by, people move on and are replaced, and we take it for granted that the pile of products serves an important purpose. But scratch the surface and you notice that most of these systems don’t talk to one another, there’s no shared understanding of the data, and the products have created silos. And herein lies the problem.

This is often called SaaS sprawl. More recently, people have started calling it the ‘Fragmentation Tax’, and the subscriptions are actually the least of it. The real cost is in managing the sprawl: the people whose job it is to run these systems, the people who dutifully maintain manual workarounds to get the data they need, and the people who wait days or weeks for reports because the data isn’t readily available. It’s the cost of slow decision-making, and of time sunk into low-value work instead of work that drives the business forward. We don’t have to accept this any more.

The real cost of the Fragmentation Tax

1. Your software subscriptions, and the people needed to operate them.
2. The manual workarounds needed to make data make sense across fragmented systems.
3. The delay in decision-making when information isn’t available instantly.
4. The opportunity cost of people focused on all of the above, rather than higher-value work.
5. The opportunity cost of not being able to deliver AI transformation, because the data is, basically, a fragmented mess.

Traditional ways of solving fragmented systems

Before I get to what I think the answer is, it’s worth being fair to the options already on the table. Some of them are genuinely the right call in the right situation.

1. Do nothing. Pay the tax, and perhaps bin a few licences at renewal. There’s no disruption and no upfront cost, which is why it’s the most popular option by some distance. But the tax compounds every year, and it does nothing for your AI ambitions.
2. Point-to-point integrations and lightweight automation. Connect one system directly to another, or use tools like Zapier or Make to pass data between them. Quick, cheap, and often perfectly good for a single flow. But every new system potentially needs wiring to every other, and before long you have a web of brittle connections that nobody fully understands, and nobody owns when they break.
3. Robotic Process Automation (RPA). Software ‘robots’ that mimic what a person does on screen. Fast to deploy and handy for repetitive tasks, but they break whenever a screen, process or data format changes. If I’m honest, RPA automates the workaround rather than removing it.
4. Integration platforms. Tools like MuleSoft give you robust, enterprise-grade plumbing for moving data between systems. They’re powerful but expensive and reliant on specialist skills, and they move data without deciding what that data means.
5. Data lakes and warehouses. Platforms like Snowflake or Databricks pull everything into one place so it can be queried. Genuinely useful. But without real discipline the lake becomes a swamp, someone still has to decide what a ‘customer’ actually is, and the queue for reports often just moves rather than shrinks.
6. Consolidate onto fewer platforms. Replace several systems with one larger suite or ERP. At enterprise scale this is a multi-year, big-bang bet that usually means bending the business to fit the software. At SME scale it can genuinely be the right call: moving onto a single ERP is a realistic project, not a £2bn one. But consolidation rarely gets you down to one system, and the ones that remain still need to agree.
7. Bolt on AI. Roll out some Microsoft Copilot licences and bank some quick wins. People like it, and meeting summaries alone are a decent return. But AI can only see what it’s pointed at. Ask it a question that spans your CRM, your finance system and your operations platform, and it either can’t answer or, worse, it guesses.

Look across that list and there’s a common thread. Every option moves data, reduces the number of systems, or puts a nicer front end on them. None of them, on its own, settles what’s actually true, or lets you get answers and dashboards in close to real time.

Making your tech stack make sense

So what’s the alternative? I think making your tech stack make sense means two things.

First, your systems agree with each other. One definition of revenue, one version of a customer, one source of truth for each important number.

Second, anyone can ask them a question and get a straight answer, without raising a ticket, waiting a fortnight for a report, or stitching three spreadsheets together.

You decide what’s true in traditional software first, and only then let AI talk about it. Put simply, don’t let the AI decide what revenue means.

Don’t let the AI decide what revenue means.

Here’s how we approach it at Zudu. We’ve worked on over 300 projects for clients at home and abroad, including the NHS, ScotRail and GAH. We like to start with an early conversation about the problem, and where there’s a fit, we kick off a data discovery and build from there:

1. Map how information flows. Which systems hold which data, how it moves between them, what each piece actually means to the business, how often it’s needed and what for. The technical term is an ontology, but really it’s a map of your business in data terms.
2. Agree on the metrics that matter, and why they matter. Not every number needs tracking. We focus on the handful that really move the business forward, and the decisions they inform. The ‘why’ matters: does it drive revenue, inform project staffing, reduce risk or meet a regulatory reporting obligation? If not, it’s a distraction.
3. Build a deterministic layer. A fancy way of saying we write the business rules down in traditional software, the kind that gives the same answer every time you ask the same question. The rules are tested, documented and readable, and the layer sits over the systems you already have to become your ground truth.
4. Layer AI on top. With the ground truth in place, AI can do what it’s genuinely good at: answering questions in plain English, and generating reports, dashboards and even small tools on demand, built for whoever is asking.
5. Deliver it in slices. We pick one of your most important metrics, make it make sense end to end, and get it into people’s hands. Then the next one, and the next. Value arrives in weeks, not years, which is a very different bet to a multi-year programme.

We’ve seen this pattern play out in the public sector, too. Zudu built ePass, now spun out as its own company, after finding that government licensing systems were fragmented, often built in isolation, and slow to adapt when policy changed. Rather than becoming one more standalone system, ePass was designed as shared infrastructure that connects departments and evolves with regulation. It now delivers Scotland’s national tobacco and vape register, built for more than 15,000 retailers, and the funeral services register for the Scottish Government.

This isn’t anti-consolidation, either. If you are moving onto a new platform, agreeing your definitions first makes the migration far less painful, and you keep them when you move.

Objections

I’ve tested this argument on plenty of sceptical people, so here are the questions I hear most, and my honest answers.

“Isn’t this just a data lake, or a semantic layer, with a chatbot on top?”

Partly. Data people will recognise much of the deterministic layer as what they’d call a semantic layer: one place where the business’s definitions live. Where we differ is that we start from the decision and the metric rather than ingesting everything first, you don’t need a full warehouse build before you see value, and the AI interface is part of the job, not a separate project. The AI never works from raw data; it works from agreed answers, written as rules that can be read, tested and audited. That’s the difference between a confident guess and a number you’d put in front of your board.

“Won’t AI hallucinate our data?”

On its own, it can, even if it’s getting better all the time. That’s exactly why the deterministic layer comes first. The AI asks the ground truth for the number rather than inventing one, and every question and answer is logged so you can check its working.

“We’ve already invested heavily in our systems.”

Good, keep them, or at least the ones that are useful. This sits over what you already have rather than replacing it. The aim is to remove the cost at the seams, not to start again.

“We bought SaaS precisely to avoid custom software.”

That was probably the right call for your business a few years ago. But the cost of building software has fallen sharply, and AI is a big part of why. What matters is that it’s built properly: tested, documented and maintainable, not just built quickly.

“Aren’t we just swapping lock-in to a software vendor for lock-in to you?”

You’re choosing a supplier relationship over a product licence. So choose a supplier who makes it easy to leave. The code lives in your own repository; it’s built on standard, widely used technology that your own team or another supplier could pick up; the business rules are documented in plain English; and there’s a proper handover, or training for your internal team. For larger organisations with their own data and engineering teams, we work alongside them rather than around them. Like any software, it needs looking after, so yes, there’s a services cost. The difference is that you own the result, and it’s shaped around your business rather than someone else’s product roadmap.

“Won’t AI-generated dashboards and tools just create a new kind of sprawl?”

They would, if each one worked from its own data. That’s why they don’t. Everything generated sits on the same ground truth, so two dashboards can’t disagree about revenue the way two systems do today. Most of what gets generated is a throwaway answer to a question, not a new system to maintain. When something proves genuinely useful, it gets promoted into the maintained layer deliberately, with an owner, rather than becoming the 958th system.

“But Shaun, your business builds custom software. Aren’t you biased?”

Fair challenge, and you should weigh my view accordingly. But I’d put it the other way round. I don’t advocate this approach because I work at Zudu; I work at Zudu because I believe in this approach.

Conclusion

Every organisation I work with, whether it runs 30 systems or 957, has its own version of this tale. SaaS bloat brought about the opaque Fragmentation Tax. It shows up in the manual work at the seams of these systems, and it needs addressing now so businesses can focus on higher-value work, make decisions faster, and make truly transformational change with AI. Most businesses have been told the story ends one of two ways: cut the list down, or buy one more system big enough to swallow the rest.

I don’t think it has to. Sometimes trimming the list is the right move, but it’s rarely the whole answer. The systems you have were mostly bought for good reasons, by good people, solving real problems. Most of them don’t need replacing. They need to agree with each other, and then they need to be easy to ask. That’s where the real AI gains are hiding: not in another chatbot, but in a business that finally knows what’s true and can talk to it.

You don’t need fewer systems. You need them to make sense.

---

I’m Shaun Marrinan and I head up the commercial team at Zudu, a software delivery and AI-enablement partner based in Edinburgh. You can see some of our work on our projects page, and if you’d like to chat, get in touch.