SaaS Sprawl: How to Stop Paying for 23 Tools That Don’t Talk to Each Other

Many companies have no idea how many subscriptions they’re currently paying for; they can only guess, and they’re always guessing too low. One founder of a 12-person company recently went through and did a count: 23 subscriptions at roughly £3,200 in total, per month. Five years earlier, the same company had spent just under £1,000. Nothing major changed in the interim, there was no big decision that doubled it overnight. Rather one tool at a time came on board, relieved some pain, and has stayed on the shelf ever since.

This is SaaS sprawl, and if you’re building a fast-growing company you’re probably already living through it. The pattern across companies of any size is more or less the same: tools added, never removed, total price increases while value either remains stagnant or decreases. Recent benchmarks put the average small company at over 150 apps, and enterprises at several hundred. Teams are adding a new app every few weeks and not removing any.

The good news is, it’s a solvable problem. The not-so-good news is, the usual instinctive reaction (rage cancel everything when you receive the annual bill) is likely to make matters worse. Here’s some advice on how to approach your software stack, how you should be auditing it, how to find the useful subscriptions, and how you can start making real progress away from the mess.

The bill is the smallest part of the cost

What you get billed is what you see, but that is almost never where the vast majority of your cost actually sits. The real cost happens in the spaces between tools.

When your CRM doesn’t integrate with your invoicing software, or your invoicing software doesn’t connect to your support mailbox, somebody has to fill in those blanks. A human copies and pastes customer records across systems. A human exports a report from one program and then plugs it into a slide deck. A human notices three weeks down the road that two systems no longer agree on the numbers.

“Being a human integration layer: copying info between tools, having issues slip between cracks, nobody being able to trust any one tool to serve as a single source of truth.”
// FOUNDER, 30-PERSON UK SME

Other costs are less obvious as well. For every person brought on board, there are 20 tools to learn, not five. Every tool is another logon, another password, another security concern. Every tool is another data store, often unencrypted. Every link you do have, meanwhile, is one tenuous automation that fails as soon as a vendor switches out the APIs.

“This model works when you’re on five tools. When you’re on 50 tools, you’re in trouble.”
// HEAD OF OPS, B2B SCALEUP

The bill isn’t actually the cost. It’s a baseline. The drain on productivity, the data-quality challenges, the onboarding overhead, the security exposure: that is where the actual cost of sprawl lives. It runs far higher than what your monthly statement shows.

The tools you don’t even know you’re paying for

You can’t fix sprawl until you see it, but a meaningful slice of it has no shape and no colour. That’s shadow IT, although today it’s more accurately called shadow SaaS: a buy that goes through somebody’s corporate credit card and never sees the light of day in IT or Finance, often running with real customer data.

This happens far more than most leaders assume, almost always resulting in a shock when a full audit is performed. Research suggests shadow IT now accounts for over a third of all SaaS apps, and that organisations underestimate their true software spend by more than 300 percent.

At the high end, Adobe thought they were only using 1,800 different software programs. It turns out there were at least 2,600. Everywhere you look, the results are the same: a marketing team signs up for a customer relationship management tool that holds 10,000 customer email addresses, and IT has no idea. That’s where the shadow SaaS lives, and where the real security and compliance risks lurk.

It’s usually where you want to start fixing your audit. A tool you didn’t agree on, holding information nobody is tracking, is a threat to your company in and of itself.

Why cutting tools is harder than it looks

You could delete it if sprawl were all waste. But it isn’t. That’s why the “wipe the slate clean” approach always comes back to hurt you later. There are three barriers in the way.

Barrier 1: People

Tools have users, and users grow attached to their tools. The head of sales doesn’t want to abandon his tailored CRM platform. The creative director can’t function without her design software and the workflow tools that support it. Remove their tools without warning, and you won’t get thanks. You’ll get a complaint at best, a mutiny at worst.

“If we’d tried to rip everything out in one fell swoop, there would have been a rebellion.”
// SYSTEM ADMIN, 90-PERSON COMPANY

Barrier 2: Lock-in

Your information is at the heart of these tools. They store years of data, the custom fields, and the workflows you’ve painstakingly built. Moving that data is actual labour. Often, when you finally manage to export your information, you end up with a worse version of what you had. Worse still, the migration fails outright. And if the import goes wrong while some of the old data still hangs around, you have a different kind of disaster on your hands.

Barrier 3: Dependency

Most of these tools work together. Deactivating one of them could take down three others that rely on it. Your stack relies on itself, and while it drives you crazy, you can’t afford to break the chain.

This isn’t to say that consolidation is a fool’s errand. It’s that you have to go about it correctly. The teams who get it right never delete everything and swap in new tools in a single day. They run a process: assess what you’re using, prioritise where you want to go, then replace your software with new options in phases at the point of renewal, with executive backing for every decision made.

A practical SaaS audit you can actually run

A playbook of this type makes sense for companies in the 20 to 200-person range. It’s not a pretty undertaking or a one-off project, but an exercise you do quarterly (or at minimum, annually).

Step 1: Build the inventory

Collect the relevant data: credit card transactions, expense reports, accounting system exports, single sign-on logs. Then ask every team what software they’re actually using on a regular basis. The information from credit card bills alone is incomplete; the full count will inevitably be higher than you would have thought.

Step 2: Categorise everything

Sort by category: CRM, project management, communications, file storage, analytics, and so on. Then for every single tool in the inventory, note down:

• How much you pay for it monthly
• How many users it has
• The last time someone actually logged in
• When the renewal date falls
• What other systems integrate with it

Assign two owners to every application: one representing the business, one from IT or Finance.

Step 3: Score what you can do without

Once you have an accurate picture, start rating applications to determine which ones you can do without. Experienced operators score the following factors, in roughly descending order of importance:

• Usage. This ranks highest. Applications where fewer than 20% to 30% of assigned seats are active, or where nobody has logged on in the previous 30 to 60 days, are your first and most obvious candidates. Somewhere between a third and a half of paid-for licences go unused in most software stacks.
• Value compared to cost. Big-ticket applications that are infrequently used are the low-hanging fruit (don’t forget that even apps offered free of charge have their hidden costs).
• Redundancy. Two CRMs? Three different project management tools? Four messaging platforms? Odds are, you could get by with just one in each category.
• Integration quality. How well the product fits your core stack, specifically, how much manual effort (the “glue”) your team puts in to make it operate.
• Switching cost. If you had to export your data tomorrow, could you? A high switching cost sometimes helps preserve an otherwise mediocre tool, and that should be your justification for retaining it for now.
• Security and compliance. Any product that houses customer data without approval rises to the top of the list regardless of its other scores.
• Business criticality. A company-wide product plays a different role than a tool only one person uses.

Step 4: Decide and implement, slowly

Group all of your software into four buckets: keep, optimise, replace, kill. Do not implement all of them immediately. Spread implementation over renewal dates. Grandfather products for current users and move to a new product when the renewal date arrives. Establish an approval system for all new spending so that the sprawl doesn’t simply resume.

Step 5: Monitor

Create renewal notifications and budget thresholds, and perform a similar audit again next quarter. You’ll quickly find the actual audit is the easiest step. Ensuring your sprawl does not expand again is the harder task. That’s only possible if executives and finance teams are strict about the approval process.

How much can this save you?

For a small company, cutting away the obvious fat may result in cost savings of between £5,000 and £20,000 per year, plus the time and energy that have been going uncounted for years. One firm was able to remove eight of its 19 apps without any employees in the office even registering the difference.

In a 100 to 200-person company, disciplined audits can yield six or seven figures per year. Take one tech startup that expanded from 150 to 800 employees. The firm went from running 74 apps to 45, saving around £240,000 per year, a 30 percent reduction in its software cost growth rate.

Three ways out: cut, consolidate, or build

Having your entire stack in view now makes every decision a choice between three options.

Cut

This is the simplest and most important option. Remove anything no one is actually using, eliminate redundancies, and get rid of any shadow tools that are not secure or compliant. This is all upside, no downside. It’s also the biggest pool of low-hanging fruit. If you’re avoiding anything more complicated, it makes perfect sense to prioritise cutting first.

Consolidate

This means combining the duties of several tools onto one larger platform. A platform can truly reduce fragmentation. However, to put it fairly: all-in-one platforms are almost always slightly worse at every single function than the specialist tools they’re replacing, and you’re trading many small lock-ins for one big one. Sometimes that trade-off makes sense. Sometimes the platform ends up loaded with features you’ll never use, and you’re back where we started.

Build

This is the most transformative option, especially over the past two years. For a certain class of problems, replacing several point tools with a single bespoke one that does exactly what you need is now a genuinely sensible choice. This is the heart of the build vs buy software question, and the signal is often the same: you pay for three or four tools to get the result you want, you only use 10 to 20 percent of any one of them, and what you really need is the tiny area where all three overlap.

The economics can be staggering. One organisation traded three applications totalling £88 per month for a bespoke alternative costing £15 per month, while removing six hours of weekly manual effort. Another team rebuilt a £200-per-month product over a weekend, for next to nothing ongoing. These aren’t anecdotes. The latest 2026 survey by Retool reports that 35% of teams had already replaced at least one SaaS tool with custom-built software, and 78% say they’ll make more such replacements in 2026.

Here’s where AI tips the scales: an internal tool that previously took months to build now takes a few weeks to get to 80% done with the help of AI. That’s where the line between worthiness to make and to buy shifts. If you’re at the point of weighing those trade-offs, our custom AI software work and AI workflow automation service both start from exactly this calculation.

When you should absolutely not build

There’s a landmine on the build path. Let me be blunt: AI takes you to the first 80% right out of the gate, but then we get stuck in that last 20%. The edge cases, the scale, the security, the mundane reality of operating a product in an environment that never stops changing because browsers and APIs never stop changing.

Fragile custom tools built at speed, by developers who don’t have the deep expertise to make them scale reliably, will work perfectly until they don’t. And when they don’t, there’s no one to fix them. The real cost of development isn’t the building. It’s the ownership.

So keep buying. Keep buying payment processing with Stripe. Keep buying authentication, SSO, and MFA. Buy anything that has heavy compliance, has a complex visual editing interface, or needs an SLA and a helpdesk.

The rule that holds up forever is this: build what’s unique to what you do, and buy what any business can use and nobody should reinvent.

It’s important to add that the right choice is rarely black or white. This is the real answer to the SaaS vs custom software debate. The best approach is usually a mix: keep using high-quality third-party services where they exist, and build a layer that integrates them and runs the workflow on top. Connecting your existing stack with AI integrations is often a faster and cheaper win than ripping the stack out wholesale.

The goal shouldn’t be to tear apart the stack. It should be to build the glue, the code, and the logic that makes your stack run itself. If your team is the glue, you have a real problem. The glue is usually where most of the value sits, and it’s often a much easier and less risky thing to build yourself than the apps it connects.

Where this leaves you

SaaS sprawl is structural. It’s easy to buy a new tool, often considered optional to remove one, and the stack will naturally grow unless you make a conscious effort to stop it.

Don’t throw out everything you have. Just get an honest accounting of what you currently have, set standards for what your tools can and can’t do, and think hard before you decide to replace an app.

For most companies, the first win is simply removing unused apps and clearing out the shadow IT tools you’re paying for without realising. If you’re finding you’re paying for multiple tools to accomplish the same thing, it may be time to look for a single toolset that meets your needs.

We start with that mindset at Pixelfield. Tell us how you work, where you’re having trouble, and give us data to work with before we start coding. Most often, our advice is to reduce first and build nothing. In other cases, we’ll suggest replacing a handful of apps with one unified platform that provides everything you need, and nothing more.

For the build side of the build vs buy question, see our Complete Beginner’s Guide to AI Agents for SMEs. For the knowledge side (the “AI that knows your business” use cases), see Practical RAG for UK SMEs.