SaaS sprawl in 2026: the numbers.

A number stopped me a while ago. Industry surveys of software management, the kind published each year by vendors who audit corporate app estates, have reported the average company running on the order of a hundred or more paid SaaS applications, with large enterprises counting into the several hundreds. When I first read figures like that I assumed they were inflated to sell a product. Then I counted my own tools, and my collaborators counted theirs, and the number stopped looking like marketing. It started looking like an honest census of how modern work actually gets stored.

This post is a roundup of what the data says about SaaS sprawl in 2026, told as plainly as I can manage. I will attribute figures to the kind of source they come from rather than invent a decimal to sound precise, because the shape of the trend is what matters and the shape is not in dispute. The count is high, the waste is real, the spend is climbing faster than the value, and the reasonable response is to run fewer things on purpose.

How many apps a company actually runs

Start with the headline count. Reports from software-spend management firms have for several years put the typical mid-market and enterprise company somewhere between roughly one hundred and three hundred paid applications, and the figure has trended up rather than down across those reports. Small companies run fewer in absolute terms but often more per head, because a five-person team that adopts a tool for each function ends up with a longer list per person than a thousand-person company with central procurement.

The more revealing number is not the total but the growth rate. The same surveys tend to show the app count rising year over year even during periods when budgets tightened and hiring slowed. That is the part worth sitting with. If tool count moved with headcount, sprawl would be a scaling story and nothing more. It does not. Applications accumulate on their own schedule, added faster than they are ever removed, because adding one is a single expense approval and removing one requires someone to notice, migrate, and cancel. Addition is easy. Subtraction is work nobody owns.

How much of it goes unused

Here is where the census turns uncomfortable. License-utilization studies, again from the firms that audit these estates for a living, have repeatedly found that a substantial share of purchased SaaS licenses go unused or barely used. The commonly cited range lands around a quarter to a half of licenses sitting idle, depending on the tool category and how strictly you define active use. Seat-based collaboration tools tend to fare worst, because companies buy in bulk and provision optimistically.

Redundancy compounds the waste. The same studies report that a meaningful fraction of applications in a typical estate overlap in function with at least one other application the company already pays for. Two project trackers. Three places to store documents. A CRM that the marketing team supplements with a second lightweight CRM because the first one felt heavy. None of this is irrational at the moment of purchase. Each tool solved a real, local problem for the person who bought it. The redundancy only becomes visible when someone finally lists every subscription on one page, which most companies do far too rarely.

The spend keeps climbing on flat headcount

The financial trend is the one that reaches the boardroom. Across the annual state-of-SaaS reports, spend per employee on software has generally risen year over year, and it has risen through stretches when companies were not adding people. That decoupling is the crux of the sprawl problem. When cost tracks headcount, finance can reason about it. When cost climbs while headcount is flat, the software line item behaves like a leak, and leaks are hard to fix because no single subscription looks large enough to bother with.

That is by design, though not by conspiracy. Per-seat, per-month pricing is engineered to feel small. Twelve dollars a seat does not trigger scrutiny the way a six-figure contract does, so it clears approval fast and renews automatically. Multiply a dozen such tools across a few hundred people and the quiet total rivals a serious hire. I have written before about the real bill hiding underneath these small numbers, and the accounting is worse than most teams expect once you add the human cost on top of the invoices. The subscriptions are only the visible layer.

The cost the invoices do not show

Every tool you add is not just a line on a statement. It is a login to manage, a permission model to keep current, an integration to maintain, an onboarding step for every new hire, and a place where a piece of the truth now lives apart from the rest. The invoice captures none of that. The hidden cost sits in the time people spend moving between systems, reconciling records that disagree, and searching four places for a document that should have been in one.

Research on knowledge work, including studies covered by outlets like Harvard Business Review, has described how much of the day gets lost to switching between applications and reorienting after each switch. When work is spread across many tools, that switching is not a personal discipline problem. It is manufactured by the structure of the stack. I have laid out the full accounting of this elsewhere, and it is the strongest argument I know for treating tool count as a first-class metric rather than an afterthought. You can read the deeper version in the real cost of running your team on eleven tools.

Why sprawl grows even when everyone wants less of it

Almost no one sets out to build a sprawling stack. It grows because the incentives at the moment of each decision all point toward adding. A team hits friction, finds a tool that removes it, and the tool is cheap enough to expense without a meeting. The person who adopts it gets the benefit immediately. The cost, spread across IT, security, finance, and everyone who now has one more place to check, arrives later and lands on other people. That asymmetry is the engine. Local benefit, distributed cost, repeated a few hundred times.

Shadow adoption widens the gap between the official count and the real one. Surveys of IT leaders consistently find that a large portion of the applications in active use were never approved centrally, which means the audited number of a hundred-plus is usually a floor, not a ceiling. You cannot manage what you have not counted, and most organizations have not finished counting. The first honest step is not consolidation. It is a full inventory, because sprawl thrives in the dark.

Consolidation as the rational response

If the count is high, the waste is real, and the spend is decoupled from value, then the rational move is to run fewer tools deliberately. I want to be careful here, because consolidation is easy to preach and hard to do well. Cutting tools for the sake of a lower number can push work into spreadsheets and email, which is sprawl by another name. The goal is not fewer logos. It is fewer places where the same work lives, so that a task, the project it belongs to, and the customer it serves sit in one structure instead of three products that have to be kept in sync by hand.

That is the case for a single system rather than a drawer of specialized tools. When the work shares one data model, the redundant apps have nothing left to be redundant about, the idle licenses stop accumulating because there is one thing to provision, and the switching cost falls because there is less to switch between. This is the whole reason I build Atlas the way I do: one work graph holding tasks, projects, documents, and records together, with an assistant that acts on that shared structure rather than bolting a chat box onto yet another silo. Consolidation is not a slogan for me. It is the product thesis.

If you want the practical version rather than the argument, I have written two step-by-step guides. One walks through how to reduce SaaS tool sprawl without breaking the workflows people rely on, and the other covers how to consolidate your SaaS stack in an order that keeps the business running while you cut. Both start the same way: inventory everything, then remove what overlaps before you remove what is merely underused.

What to do with these numbers

The point of a roundup like this is not to alarm you into a purchase. It is to give you a defensible baseline. If your company runs somewhere north of a hundred applications, if a quarter or more of your licenses are idle, and if your per-head software spend has climbed while your team has not, you are not an outlier. You are the median, and the median is expensive. The useful response is to measure your own estate against these ranges, find where your redundancy and idle spend actually sit, and consolidate the overlaps first, because those are the cuts that reduce work rather than merely reduce cost.