From Shubhi K | Product & Market Analysis
The 291-App Problem: SaaS Sprawl Meets the Budget Axe
On this page
The average enterprise ran 291 SaaS applications in 2025, up from 110 in 2020. That is a 164% increase in five years, and almost none of it was a deliberate decision by anyone with responsibility for the total. Finance teams are now auditing every renewal against an AI alternative, and most of those audits are being run badly.
Key takeaways
- Application counts nearly tripled in five years. The average enterprise ran 291 SaaS applications in 2025 against 110 in 2020.
- Sprawl is an accumulation, not a decision. Nobody approved 291 applications. Each one was approved individually by someone with a real problem.
- Licence cost is the smallest cost. Integration maintenance, access administration, security review and context switching all exceed it.
- Most rationalisation exercises fail on adoption, not analysis. Cancelling a tool people depend on without replacing the capability produces shadow spend rather than savings.
How it got to 291
The number itself is worth sitting with. 291 applications in 2025 against 110 in 2020 means an organisation added, on average, roughly three applications a month for five years.
No executive approved that trajectory. It happened because software buying decentralised. Individual teams gained the authority to purchase tools on departmental budgets, and each purchase was a reasonable answer to a real problem.
The failure is one of aggregation rather than judgement. Three hundred good decisions can produce a bad outcome when nobody holds responsibility for the total, and no single approval process ever sees more than one application at a time.
Why sprawl happens even in well-run organisations
Four mechanisms, none of which involve anyone behaving badly.
The four mechanisms
Decentralised purchasing. A team lead with a corporate card and a $50 per month problem does not raise a procurement request, because doing so would take longer than the problem is worth. Multiply that entirely reasonable calculation by every team in the organisation over five years.
Overlapping capability. Two departments solve the same problem with different tools because neither knew the other had the problem. This is the largest single source of duplication.
Acquisitions. Every company acquired brings its own stack, and consolidating it is always scheduled for after the integration that never fully finishes.
Nobody owns cancellation. Buying software is somebody's job and cancelling it is nobody's, which means an unused subscription generates no complaints from anyone in the organisation. Silence is not the same as absence of cost.
Why none of these self-correct
Each mechanism produces a cost that lands somewhere other than where the decision was made. A team buying a tool creates integration work for engineering, access work for IT and review work for security, and pays none of it from its own budget.
That is the structural reason sprawl persists in organisations that are otherwise well run. It is not a discipline problem. It is a problem of costs and decisions sitting in different places, and no amount of exhortation fixes it.
What sprawl actually costs
Licence spend is the number that appears in a budget review, and it is the smallest of the four costs.
Integration maintenance scales with connections rather than applications. Every tool that talks to another tool creates a link somebody has to keep working when either end changes.
Access administration is a per-person, per-application cost that arrives every time someone joins, changes role or leaves. At 291 applications, offboarding a single employee is a substantial task.
Security and vendor review grows with the count directly. Each application is a vendor relationship, a data processing agreement and a potential breach path.
Context switching is genuine and hard to quantify. Staff moving between a dozen tools to complete one process lose time that appears in no budget line.
The number that makes the case
If you need one figure to justify the exercise internally, use offboarding time. Calculate how long it takes to fully remove one departing employee's access across every application.
At a few dozen applications this is an afternoon. At 291 it is a project, and it is a project that gets done incompletely, which is a security exposure rather than an inconvenience. That framing gets budget approved where a licence-saving argument does not.
How to run the audit properly
Most rationalisation exercises start with a spend report, which is the wrong starting point because it ranks by the smallest cost.
| Step | What to do | Why this order |
|---|---|---|
| 1. Inventory | Pull every application from expense data, single sign-on logs and network traffic | Expense data alone misses anything on a personal card or a free tier |
| 2. Map to capability | Group applications by the job they do, not by department or vendor | Duplication only becomes visible when grouped by function |
| 3. Measure real usage | Active users in the last 30 days, not licences purchased | Licence counts and usage diverge dramatically after year two |
| 4. Identify the owner | Find the named person who depends on each tool | Tools with no owner cancel cleanly. Tools with one need a conversation. |
| 5. Sequence cancellations | Start with zero-owner, zero-usage, then duplicates | Early wins fund the political capital for the harder decisions |
Step 1 is where most audits are incomplete. Expense data captures what finance pays for. Single sign-on captures what IT provisioned. Neither captures the tool a team is using on a free tier with company data in it, and that category has grown considerably since AI tools started offering generous free access.
What the audit usually reveals
Three findings recur across organisations that run this properly, and none of them is the one people expect.
The first is that the largest single category of waste is not unused licences. It is duplicate capability, where two or three teams pay for different tools solving the same problem, all of them actively used.
The second is that licence counts and active users diverge sharply after about eighteen months. A tool bought for a department that has since reorganised is still being paid for at the original seat count.
The third is the shadow inventory. Tools in active use with company data in them that appear in neither the expense report nor the identity provider, usually on free tiers or personal cards.
What to cancel, and in what order
Sequence matters more than the analysis, because a rationalisation programme that starts a fight in month one does not reach month six.
First: zero usage, no owner. Applications nobody has logged into for ninety days with no identifiable champion. These cancel without a conversation and they establish that the exercise produces savings.
Second: genuine duplicates. Two tools doing the same job for different teams. Pick one, migrate the other, expect resistance proportional to how long the losing team has used theirs.
Third: point products in absorbed categories. Anything whose function is now adequately covered by a platform you already pay for. Gartner projects roughly 35% of point products being absorbed by 2030, and this is where that projection becomes a cancellation list, as covered in the analysis of category absorption.
Last, or never: anything load-bearing. Systems of record, anything with an audit obligation, and anything a customer-facing process depends on. The savings are real and the risk is disproportionate.
Why most rationalisation exercises fail
Three failure modes, and they are predictable enough to plan around.
The three failure modes
Cancelling capability rather than duplication. If people were using a tool, they had a reason. Remove it without replacing the capability and the work does not stop, it moves to a spreadsheet or a personal account. The spend disappears from the budget and the cost does not.
Treating it as a one-time project. Sprawl accumulates continuously. An organisation that runs a cancellation exercise and declares victory is back at the same count within three years, because the mechanisms that produced it are untouched.
No change to the buying process. The single highest-return action is not cancelling anything. It is requiring that any new application purchase names the existing tool it replaces. That one rule does more than any audit.
Where this advice is wrong
Three honest caveats.
Sprawl is partly a feature. Decentralised purchasing exists because centralised procurement was slow enough to block teams from solving their own problems. A rationalisation programme that restores central control may cost more in delivery speed than it saves in licences.
The 291 figure is an average across organisations of very different sizes and sectors, and the average is doing a lot of work. A 200-person company with 291 applications has a different problem from a 50,000-person one with the same count.
And the cost weighting in this post is directional rather than measured. No published dataset compares integration maintenance cost against licence spend at scale, so the ranking reflects a structural argument rather than an observation.
The honest position is that sprawl is expensive in ways that are hard to quantify and easy to feel, which is exactly the kind of problem that gets ignored until a security incident or a budget review forces it into view.
Frequently asked questions
How many SaaS applications does the average company use?
The average enterprise ran 291 SaaS applications in 2025, up from 110 in 2020. That is a 164% increase over five years, accumulated at roughly three applications a month. The figure is an average across organisations of very different sizes, so it should be read as an indication of the trend rather than a benchmark for any specific company.
What does SaaS sprawl actually cost?
Licence spend is the smallest of four costs and the only one that appears in a budget review. Integration maintenance scales with connections between tools. Access administration arrives every time someone joins, changes role or leaves. Security and vendor review grows directly with application count. Context switching costs staff time that appears in no budget line.
How do I audit our SaaS stack?
Five steps in order. Inventory from expense data, single sign-on logs and network traffic together, since none alone is complete. Group applications by the job they do rather than by department. Measure active users in the last thirty days rather than licences purchased. Identify the named owner of each tool. Then sequence cancellations starting with zero-usage, zero-owner applications.
What should I cancel first?
Applications with no logins in ninety days and no identifiable champion. They cancel without a conversation and they establish that the exercise produces savings, which funds the political capital for harder decisions later. Genuine duplicates come second, then point products whose function is now covered adequately by a platform you already pay for.
Why do SaaS rationalisation projects fail?
Usually because they cancel capability rather than duplication. If people were using a tool they had a reason, and removing it without replacing the function moves the work to a spreadsheet or a personal account. The spend leaves the budget and the cost does not. Treating it as a one-time project rather than a continuous process is the second failure mode.
What is the single highest-return change?
Not cancelling anything. It is requiring that any new application purchase names the existing tool it replaces. That rule addresses the mechanism producing sprawl rather than the accumulated result, and an organisation that runs an audit without changing the buying process returns to the same application count within about three years.
Where to start this week
Do not start with a spend report. Start with the inventory nobody has.
Pull your application list from three sources rather than one: expense data, single sign-on logs and network traffic. The gap between them is the interesting part, because it contains every tool being used with company data that finance and IT do not know about.
That gap is usually larger than anyone expects, and it is a security finding as much as a cost one. Present it as both and the rationalisation programme gets funded on the first attempt, where a licence-saving pitch would have been deferred to next quarter.
Then change one thing in the buying process before you cancel anything. Require every new application request to name the existing tool it replaces, even where the answer is none. That single rule addresses the mechanism rather than the symptom, and it is the only part of this exercise that still works in three years.
References
- Fortune Business Insights and BetterCloud, 2025. Used for the 291 and 110 application counts.
- Gartner projection via Deloitte, 2025, on point-product SaaS absorption into agent ecosystems by 2030.
- TechCrunch, SaaS in, SaaS out: what's driving the SaaSpocalypse, 1 March 2026. Used for enterprise software rationalisation context.
- Long Angle, Software vs AI Q1 2026. Used for spending pressure and market context.
The cost weighting in this post is a structural assessment rather than a measurement. No published dataset compares integration maintenance and administration costs against licence spend at scale, and the ranking reflects that argument rather than survey data.
Related reading