• A company with 75–199 employees uses an average of 44 SaaS applications[1]. Ask around before you count, and see what number comes back.

• Workers toggle between apps roughly 1,200 times per day, losing about four hours a week just reorienting after each switch[2]

• The subscription bill is the cheapest part of sprawl. The data silos and security blind spots underneath it cost more and show up nowhere

• Cutting tools rarely fixes it. Fixing the workflows that run between them usually does, and the tools stay exactly where they are

Ask someone on your team how many software tools the business runs on. They'll probably say ten. Maybe fifteen.

Nobody has measured how wrong that guess usually is, so we won't pretend to. But the other half of the comparison has been measured, and it isn't close.

Productiv's 2024 data puts a company with 75 to 199 employees at an average of 44 SaaS applications.[1] BetterCloud's 2024 State of SaaS report put the average across all company sizes at 106, down from a peak of 130 in 2022.[3]

Both of those companies sell SaaS management software, so read the figures as a ceiling rather than a target. Even read that way, 44 is a long way from fifteen.

That gap has nothing to do with carelessness. Software gets adopted one team at a time, one problem at a time, and nobody anywhere is keeping a register.

What you don't know about, you can't manage. Every untracked tool is a billing line nobody reviews and a data silo that somebody on your team is quietly bridging with copy-paste. The industry calls this SaaS sprawl (sometimes app sprawl). Whatever you call it, if you haven't counted recently, you're living with more of it than you think.

Here's how to count what you've actually got, what the sprawl costs you in the places no invoice reaches, and which gaps are worth closing first. The counting takes an afternoon.

Where they all came from

SaaS sprawl doesn't happen because someone made a bad decision. It happens because everyone made a reasonable one.

Marketing needed an email platform, so they signed up for Mailchimp. Sales wanted a CRM, so someone started a HubSpot trial. Operations needed shipping labels, so they added ShipStation. Finance needed invoicing, so they set up Xero. Every one of those was the right call on the day it was made.

Nobody was looking at the whole picture, and most of the growth happens where the picture doesn't reach. Gartner puts it at 41% of employees acquiring, modifying or creating technology outside IT's visibility, rising to a projected 75% by 2027.[4] Big companies file that under shadow IT and staff a team to chase it. In a small business without a dedicated IT function, nearly everything is shadow IT, and the team chasing it is you.

There's no malice in any of it. The marketing intern signed up for Canva with the company card. Someone on the ops team started tracking projects in Notion. A developer spun up a Supabase instance for one workflow and moved on.

Nobody decides to own forty-four tools, in the same way nobody decides to own nine phone chargers. The pile just grows, and nothing ever gets thrown out. Three tools that do project management. Two that handle file storage. A handful of niche apps that one person uses for one task, which nobody else could name under oath.

How to audit your stack

The process is simpler than you'd expect. The results are less comfortable.

Start with the money. Pull twelve months of company card and bank statements, and write down every recurring charge from a software vendor. You'll find things you'd forgotten you were paying for.

Everybody does. The first count always comes in worse than the guess, and it comes in worst for the people who were certain it wouldn't.

Next, check your identity provider or SSO dashboard. Most small businesses don't have one, so look at the Google Workspace or Microsoft 365 admin panel instead. That shows which third-party applications have been granted access through OAuth, which is the "Sign in with Google" button your team clicks without reading. Zylo's 2025 SaaS Management Index found that organizations use just 47% of the SaaS licenses they pay for.[5] Less than half, across the whole stack. (Zylo sells a tool that finds idle licenses, so of course they would say that. Every company quoted in this article has a horse in the race, us very much included.) Canceling the idle ones is the fastest win an audit produces, and it usually pays for the afternoon you spent finding them.

Then the awkward part. Ask your team, and ask in writing so the answers are on a page rather than in a corridor:

What tools do you use every day?

What do you use a few times a month?

What do you pay for yourself and expense?

What are you using that you're fairly sure nobody else knows about?

People will name things that appear nowhere in your financial records. Browser extensions, freemium accounts, a trial from 2023 that nobody canceled. They all count, because they all touch your data.

Call them corridor tools. They live in one person's head and one person's browser, and the day that person leaves, they go quiet without anyone noticing.

Finally, sort the list by what each tool actually does. CRM, email marketing, project management, accounting, shipping, file storage, analytics. This is where the overlaps jump out. Two teams on two different project trackers. Three apps that can each email a customer. A spreadsheet doing a database's job because nobody knew the CRM already had that feature, which happens more than you'd think.

The hidden costs

The subscription bill is the visible cost, and Zylo's 2025 data puts average SaaS spend at $4,830 per employee per year.[5]

It's also the least interesting number, because almost nobody connects it to the work it's supposed to support. For one multichannel retailer we spread every recurring subscription across the orders it helped produce. A monthly bill nobody questioned became a cost per sale somebody could act on.

The operational costs are worse, and they compound quietly.

The big one is time lost moving between disconnected systems. A 2022 study published in Harvard Business Review tracked workers across three Fortune 500 companies and clocked roughly 1,200 toggles between applications in a single day. Twelve hundred! That worked out to four hours a week spent reorienting after each switch, or about five working weeks a year.[2]

In a small business it's worse than tab-hopping. The systems share no data at all, so on top of losing their place, people retype what the other system already knows. There's a reason "app fatigue" turned into everyday vocabulary on operations teams.

We see it constantly. One client had a sales team that left their order management system to check warehouse stock in a separate portal before every order, because the two tools didn't talk. Nothing dramatic ever went wrong. It was a slow, steady drain on time and accuracy that everyone had long since accepted as normal.

Security hides in plain sight too. Every tool that touches your data is a door into the building, and nobody has drawn the floor plan. You can't enforce a password policy on something you don't know exists. When someone leaves, their access leaves with them only in the sense that nobody revokes it. With Gartner projecting 75% of employees adopting technology outside IT's visibility by 2027,[4] that surface only grows.

Then there's onboarding. Every new hire has to learn a dozen tools, each with its own login and its own small ways of being weird. The onboarding period stretches, mistakes go up, and tribal knowledge becomes the only documentation that matters. When someone leaves, they take the understanding of how all the pieces fit together with them. You don't lose a person. You lose the wiring diagram.

Why "just use fewer tools" fails

Faced with a list that long, the instinct is to start cutting. Some consolidation genuinely does make sense.

All-in-one platforms like HubSpot or Zoho work well for businesses with straightforward workflows. If your needs are standard, one platform covering CRM, email marketing and basic automation is simpler to manage and cheaper to run than four best-of-breed tools you have to wire together yourself. Fewer vendors, and one support queue to shout at. We've watched that work.

That suitability has a ceiling, though.

The all-in-one that handles CRM, email marketing, project management and invoicing does each of them adequately and none of them well, which stops being acceptable the moment your requirements get specific. Your marketing team chose their email tool for its segmentation. Your operations team chose their inventory system because it handles multi-warehouse logic. Swap both for one platform that does neither properly and you've traded a sprawl problem for a capability problem, and customers notice the second one.

Here's the thing the count hides. A business running 100 tools that talk to each other is in better shape than a business running 15 where somebody spends every morning reconciling three of them by hand. Sprawl is the symptom you can see. The work happening in the gaps is what actually costs you.

So the more productive question is how to make what you already own behave like one system. When an order lands and stock updates across every channel on its own, and those changes reach your accounting platform without anyone touching a spreadsheet, you've solved the sprawl problem without deleting a single tool.

One client was spending 20 minutes on every lost-parcel compensation claim, cross-referencing their shipping platform against their accounting platform by hand. Both tools were fine. The gap between them was where 240 hours a year went.

Now the obvious disclosure: SaaS Glue does this for a living, so of course we lean toward "connect them" over "replace them." Weigh that accordingly. What we can tell you is which one sticks. Consolidation projects stall, because people fight to keep the tool that works for them, and they usually win. Workflow projects tend to land faster, because nothing changes for the person doing the job. Their screens stay the same. The data just starts arriving on its own.

What to fix first

You won't do all of it at once, and you shouldn't want to. The value of the audit is that it shows you where manual work and data mismatches are costing you the most. Start there.

Look for the places where a person is the middleware. Who is copying data out of one system and into another? Where does a process stall because the information lives in a tool the next person can't open? Where have errors crept in because something got re-keyed instead of synced?

Then rank by who finds out. Anything that touches money or stock goes first, because that's where a mistake stops being an internal annoyance and starts being a customer's problem. A broken sync between your store and your warehouse doesn't just confuse the office. It oversells stock you don't have, and the customer finds out before you do.

For lighter work (form submissions landing in a CRM, a Slack ping when a deal closes) Zapier or Make are perfectly adequate, and a great deal cheaper than anything we'd build you. Save the custom work for the connections where reliability actually matters, and where having someone who owns it long term changes the outcome.

Living with sprawl, deliberately

Sprawl isn't going away. Your SaaS bill went up last year, and so did everyone else's. Gartner forecasts SaaS end-user spending growing at nearly 20% year on year, with SMBs now projected to put more than half their technology budget into cloud services.[6] Next year you'll buy something else, because next year somebody on your team will have a problem that a monthly subscription solves by Friday.

The question is only whether it happens deliberately or by accident.

So put the audit in the calendar once a year, in the slot next to the insurance renewal, and let it be rough. A half-day that produces a categorized list of your tools, what they cost, who uses them and how data moves between them will tell you what to cancel and where the expensive gaps are. It will also tell you which corridor tools have quietly become load-bearing, which is worth knowing before the person holding them books a holiday.

Nobody needs a pristine, minimal stack. What helps is a stack you understand, where the workflows that matter run on their own and nobody is carrying data across the gaps by hand. Get that far and the count stops being a problem. It's just trivia about your own company.

The gaps between your tools cost more than the tools do.

We built SaaS Glue around one idea: your team shouldn't be the middleware between your software.

Once you've done the counting, the harder question is which of those gaps is worth paying to close, and in what order. We wrote that one out as a calculation with real numbers, and it's the sensible next thing to read if your list came back longer than you expected.

Two more this post left alone. If your plan for most of the gaps is "we'll just Zapier it," here's where that stops working. And once something is built, somebody has to own it on the Tuesday it breaks, which is the question nobody asks until asking gets expensive.

If you'd rather talk it through than read more of us, get in touch.

References

[1] Productiv – 2024 State of SaaS Trends: Growth. Available at: https://productiv.com/state-of-saas/2024-saas-trends-growth/

[2] Harvard Business Review – How Much Time and Energy Do We Waste Toggling Between Applications?, 2022. Available at: https://hbr.org/2022/08/how-much-time-and-energy-do-we-waste-toggling-between-applications

[3] BetterCloud – 2024 State of SaaS Report. Available at: https://www.bettercloud.com/monitor/the-2024-state-of-saasops-report/

[4] Gartner – Managing the Risks of Shadow IT, 2022. Available at: https://www.gartner.com/en/articles/what-is-shadow-it

[5] Zylo – 2025 SaaS Management Index. Available at: https://zylo.com/reports/2025-saas-management-index/

[6] Gartner – Forecast: Public Cloud Services, Worldwide, 2024. Available at: https://www.gartner.com/en/newsroom/press-releases/2024-11-19-gartner-forecasts-worldwide-public-cloud-end-user-spending-to-total-723-billion-dollars-in-2025

• Zapier, Make and n8n are the right first move for simple, linear workflows. Skipping them to build something custom is usually just an expensive way to be early

• The breakpoints cluster in three places: logic too tangled for a visual builder, failures that nothing catches, and volume or cost outgrowing what the platform was priced for

• OutSystems found that 65% of low-code projects eventually require custom code[4], which is a strange number for a company selling a low-code platform to publish

• Outgrowing the tool happens one workflow at a time. Move the two that hurt and leave the other thirty exactly where they are

Zapier is a good product. So are Make and n8n.

Need new CRM contacts pushed into a mailing list, or a Slack message every time a form comes in? These tools have it working before lunch, with nobody's engineering time involved. More than 2.2 million businesses use Zapier.[1] That number isn't an accident.

So start there. Building something custom for a job a Zap would have done is a slow way to set money on fire.

There's a point where it stops working, though, and nobody announces it. Things just drift from "this is brilliant" to "this is held together with duct tape and prayer."

This is about where that point is, and how to tell you've reached it. Zapier gets named most often here because it's the best known, but the same ceiling hangs over Make, n8n, Power Automate, Workato and the rest of them.

And before any of it: if you've spent a month patching the same three Zaps and wondering whether you're missing something obvious, you're not. The tool is at its ceiling.

Branches on branches

"If this, then that" is fine. Every one of these tools does it well.

The trouble starts when the conditions begin depending on each other. Zapier has Paths, Make has routers, n8n has IF nodes, and Power Automate goes deepest, with its Condition and Switch controls. If you already run on Microsoft 365, that's the one to try first.

All of them branch. What none of them do well is branches that depend on each other.

Here's what that looks like on a real morning.

An order lands, and something has to decide which warehouse ships it. That depends on where the customer is. And on the product type. And on stock across three warehouses. And on the shipping method they picked. And on whether there's anything hazardous in the box.

Five inputs, each one changing what the others mean.

You can build that in a visual builder. People do. What you get back is a tree nobody can test, and nobody can safely change, because every edit risks a path they'd forgotten was there.

One client had a Mirakl-to-Mintsoft integration that split orders from several marketplace stores into sub-orders routed across several warehouse accounts. No arrangement of Zapier paths or Make routers expressed that cleanly, and the business rules kept moving anyway.

Step dependencies break in a quieter way.

Creating a fulfillment order needs an order ID from the store, a warehouse code based on current stock, and a shipping rate from the carrier. The first two can happen at once. The third has to wait for both. If either one fails, the whole thing has to stop rather than carry on with half the data.

Low-code platforms run on a pipeline. Step one, then step two, then step three. There's no clean way to say "wait for both of these, and abandon everything if one falls over," so you end up splitting the work across several Zaps that trigger each other by webhook. Now you've got three things to monitor instead of one, each with its own way of going quiet.

What happens at 2am

Things fail. Constantly. APIs return 500s, auth tokens expire mid-sync, webhooks time out, data arrives malformed. Nobody's software is at fault here. That's just Tuesday.

So the interesting question is what happens in the ninety seconds after.

What you want is retry logic that knows the difference between "try again in ten seconds" and "stop, this will never work." Somewhere to park the items that failed for good, so nothing vanishes silently. A cutoff that stops hammering a service that's already struggling. And an alert that tells you which of those just happened.

No platform in this category hands you all four. With enough scaffolding you can approximate two.

Zapier auto-retries some errors and keeps a task history you can replay by hand. Make does better, with separate routes for different error types. n8n goes furthest here: its Error Trigger node lets you build a whole second workflow just for failures.

Each one raises the ceiling a bit. Whether that's high enough is a question about your workflow rather than about the logo on the tool.

The manual replay is where it really bites. The Uptime Institute's 2024 outage analysis puts roughly 60% of IT downtime down to human error during manual processes.[5] Replaying failed tasks by hand before your first coffee is exactly that kind of process.

When an order sync fails at 2am and the retry logic is "someone checks the error log in the morning," you aren't automated. You're semi-manual with extra steps.

Webhooks make it worse, because they're fire-and-forget by design. The sending system dispatches the event and forgets you exist.

If your endpoint is down when Shopify sends an order, that order doesn't arrive late. It doesn't arrive. And if two webhooks land out of sequence, you can process a shipment update for an order that hasn't been created yet.

Handling that properly means holding events in a queue and remembering which ones you've already processed. That's a piece of engineering, not a setting.

One request per hour

We built an integration for a client whose warehouse system accepted one request per hour. One! Not one per second. Per hour.

We spent the first afternoon assuming we'd misread the docs.

There's no setting for that in Zapier. What it needs is a queue that holds work, releases it on a schedule, remembers what it already sent, and survives a restart without double-shipping anything.

That's a few hundred lines of code and a database table. It isn't a checkbox.

That one's extreme. The everyday version is milder and far more common. A downstream service allows 60 requests a minute, Friday afternoon sends 200 orders at once, and the platform's built-in retry starts politely hammering an API that's already saying no.

Every API has limits, and low-code platforms stack their own on top: polling intervals, task caps, execution timeouts, and concurrency limits you don't get to set. For most workflows that's fine. For anything time-sensitive or high-volume it's the whole game.

Nobody agrees what an address is

Systems don't agree on the shape of data, and they never will.

Your store keeps an address as one string. Your warehouse wants five fields. Your accounting tool insists on ISO 3166-1 alpha-2 country codes, and your shipping provider wants the country spelled out like a human would. One system sends dates as Unix timestamps. The next expects ISO 8601 with a timezone offset.

Low-code tools map fields and reformat text, which covers a surprising amount of this. Zapier's Formatter handles the simple cases. Make's transformation tools go further. n8n lets you write JavaScript in a Function node.

Then you hit something like this: look up this SKU in system B to get the variant ID, use that to query system C for the current price, apply the customer's contract discount, and hand the result to system D.

That's a data pipeline. Building one inside a visual editor produces something fragile and genuinely miserable to debug.

The code block tell

Every one of these platforms now ships an escape hatch. Code by Zapier. Custom modules in Make. Function nodes in n8n. Custom connectors in Power Automate. They exist because the vendors know the visual builder runs out.

Reaching for one is the clearest signal you've outgrown the tool.

When you're writing fifty lines of JavaScript into a text box with no version control, no tests, no way to run it locally and no way for a colleague to review it, what you've got is a custom integration in the worst editor ever built for one.

One or two code blocks patching an edge case, though? Fine. Genuinely, don't worry about it. But when the workflow is mostly code blocks held together by a visual editor, you're paying for the constraints of low-code and the maintenance burden of custom code at the same time.

Finding out from a customer

The message usually looks something like this:

Hey, is the stock sync running? Shopify says we've got 4 of the black ones, the warehouse says 0, and there's a customer on the phone.

By the time that arrives, it's been wrong for a while.

Low-code platforms give you task logs and an email when something fails outright. That catches the loud failures, and the loud failures are the easy ones.

It's the quiet ones that cost you. A partial failure that only hits orders with two shipping addresses. A field that started arriving empty three weeks ago. Accuracy eroding a percent at a time, with nothing ever bad enough to set anything off.

You can't set up an alert in Zapier that says "average sync time has doubled this week," or "stock levels in these two systems have drifted more than 5% apart." Those are precisely the signals that catch a problem while it's still small and boring.

We've had clients find inventory mismatches weeks after the sync started drifting, because it never technically failed. It just started being slightly wrong, and nothing was watching for slightly.

In low-code you get two states. Everything is fine, and something broke loudly enough to send an email. There's a lot of room between those, and that's where the expensive things live.

The task meter

Zapier charges by the task, and a task is any action step that succeeds. Triggers are free. So are filters, paths and Formatter steps. Everything that actually writes something somewhere is not, so a Zap with four action steps, running 1,000 times a month, costs 4,000 tasks rather than 1,000.

The arithmetic surprises people. The Team plan is \(69/month for 2,000 tasks, and that's the price if you pay for the year up front. Month to month it's \)103.50.[2] A shop doing 500 orders a day, with a stock sync and a shipping update and an accounting entry on each one, is running about 45,000 tasks a month. Twenty-two times the allowance, on a setup nobody would call complicated.

If Zapier has started feeling expensive for what it does, that's the reason. The pricing was designed around simple automations, and you're running a business through it.

Make and n8n price high volume more kindly. But cost isn't the only thing volume does to you.

Push thousands of operations a day through a visual workflow engine and it sags. Execution times stretch. Queues back up. The platform becomes your bottleneck, and your options for fixing that are whatever the vendor decided to expose.

Somebody else's servers

Everything so far has been about what the tool can't do for you. This one is about where your data sleeps.

Connect an app to a cloud-hosted low-code platform and you've handed that platform's infrastructure a key to your system. Your credentials and your data both pass through a third party.

For a Slack notification, who cares. For customer financial data or health records, it's worth a minute's thought. Self-hosting n8n removes the third party and hands you the uptime and the security patching instead, which is a real trade rather than a free win.

This matters more than it did two years ago, because of where the data goes next. Businesses are running AI workflows that push customer data through LLMs, and plenty of those route through Zapier or Make on the way.

So customer data transits a third-party platform, possibly getting logged or cached, before it reaches an AI provider whose data handling you also have to take on trust. Two hops outside your control.

With a custom integration you can run a local model inside your own VPC, and the sensitive parts never leave the building.

Neither GDPR nor SOC 2 requires that, to be clear. Both are perfectly satisfiable with third-party processors, the right contracts and some paperwork. What owning the infrastructure buys you is a shorter list of people you have to trust, and a much shorter audit.

43% of data breaches involve small and medium-sized businesses,[3] and a platform holding credentials for thousands of companies at once is a target worth somebody's effort.

The pattern

Every one of those is the same shape. The platform handles the first ninety percent beautifully and gives you almost nothing for the last ten.

The last ten is where your orders live.

Low-code vs custom at a glance

Where low-code wins

None of this is an argument for ripping out your Zaps. Most of them are doing their job perfectly well, and over-engineering something that works is its own kind of expensive.

If a workflow is linear, low-volume, and nobody's day is ruined when it fails, low-code is the right answer. Notifications. Contacts syncing from a CRM into an email tool. Form submissions landing in a spreadsheet. Social posts going out on a schedule. When the worst case is that someone hears about a new lead an hour late, the whole risk calculation is different.

Platform-native tools can beat general ones outright on their own patch. Shopify Flow handles tagging and inventory alerts inside Shopify more cleanly than any general-purpose tool manages.

Worth saying plainly at this point: we build custom integrations for a living, so "build something custom" is the conclusion we're financially inclined toward. Weigh it accordingly.

If your workflow fits in a Zap, we'll say so, and not out of virtue. A custom build for a job Zapier already does costs more and hands you one more thing to maintain.

Most businesses end up running both, and that's the right outcome rather than a compromise. Low-code for the simple things. Custom for the handful where reliability actually matters. The only skill involved is being honest about which pile a workflow is in, especially when it's quietly moved from one to the other.

How to tell

The signs cluster, and no single one of them decides it.

You spend more time maintaining an automation than it saves you. You've got a Zap that fails often enough that replaying it by hand is part of someone's morning. There's a chain of automations triggering each other and nobody can draw it on a whiteboard. Your plan cost is climbing toward what building the thing would cost. Or you've got business logic living in a Google Sheet, because no low-code tool would take it.

Three or more of those and you've outgrown low-code for that workflow. Three is a rule of thumb rather than a finding. Any one of them on its own can be lived with, which is exactly why they pile up without anyone calling it.

And it's a verdict on that one workflow, not on your stack.

The move doesn't have to be dramatic, and it shouldn't be. Pick the workflow causing the most pain, build a proper replacement for that one, and leave everything else exactly where it is.

One client came to us over their Royal Mail compensation claims, which needed AI invoice parsing and cross-system correlation before anything could be bundled into evidence. No sequence of Zaps was ever going to hold that. Everything else they were running stayed put, and still is.

A focused integration for a single workflow usually takes four to five weeks. Something spanning several systems might run to a few months. We build the monitoring first, before the thing it's monitoring, so you can watch it working from the first week rather than taking our word for it.

Low-code earned its place. It let a generation of businesses automate without hiring anyone, and most of what it's doing for you right now should carry on doing it.

Starting there is smart. Staying there after you've outgrown it is where the cost turns up, usually as somebody's morning.

We built SaaS Glue around one idea: your team shouldn't be the middleware between your software.

If you haven't counted how many tools you're gluing together yet, that's the cheaper thing to do first. And if you already know which workflow hurts, the next question is whether fixing it pays for itself, which we worked out with real numbers.

Otherwise, tell us what keeps breaking and we'll look at it with you.

References

[1] Zapier – About Zapier. Available at: https://zapier.com/about

[2] Zapier Pricing, accessed September 2026. Available at: https://zapier.com/pricing

[3] Verizon – 2024 Data Breach Investigations Report. Available at: https://www.verizon.com/business/resources/reports/dbir/

[4] OutSystems – The State of Application Development, 2024. Available at: https://www.outsystems.com/1/state-app-development-trends/

[5] Uptime Institute – Annual Outage Analysis, 2024. Available at: https://uptimeinstitute.com/resources/research-and-reports/annual-outage-analysis-2024