US Firms Run Up to 367 Apps: The Measurable Cost of Software Bloat

Large American businesses use up to 367 distinct apps and systems in their daily work, according to a recent study — and that number keeps climbing. Each tool was likely introduced to solve a specific problem, yet the cumulative effect is operational drag: harder information retrieval, slower cross-team collaboration, and productivity losses that offset the gains the tools promised.

Software bloat rarely starts as a deliberate choice. It accumulates through a predictable pattern.

How does software bloat happen?

Most organizations add tools reactively. A new system arrives when an immediate problem appears; when the next problem exceeds its capabilities, another system follows. Nobody plans the fragmentation — it emerges from incremental decisions.

Three structural drivers compound the problem:

• Department-level purchasing. In multi-team projects, departments introduce software exclusively for their own use, raising the risk of fragmented communication between teams.
• Divergent practice. Different teams develop their own processes, terminology, and ways of using technology. Without shared standards or sufficient training, the challenge grows beyond the tool count itself.
• No review cycle. A lack of regular software reviews leaves legacy systems in place, each one adding unnecessary complexity over time.

What does bloat cost in working hours?

The first symptom appears in information management. A Parseur report found that employees spend nine hours a week transferring data between systems. When information spreads across multiple platforms, it forms silos: staff spend more time locating what they need, uncertainty grows over what should be recorded, and the risk of missed key details and inconsistent records rises.

The second symptom hits collaboration. Teams with different roles tend to run separate applications that cannot work together effectively. They wait for updates that arrive inconsistently across platforms. The downstream effects are missed deadlines, increased costs, and duplicated data entry to satisfy workflow requirements — low-value workload that adds no output.

Can fewer tools raise productivity?

The article's central claim runs counter to standard buying behavior: tools introduced to boost productivity can reduce it when there are too many. Every new system is another thing employees must learn, manage, and fold into an existing workflow. When teams keep adapting to new tools without building strong foundational skills or shared practices, complexity undermines the efficiency those tools were meant to create.

Administrative effort and context switching then pull attention away from where it matters most.

The recommended countermeasures are concrete:

• Consolidate operational information where possible, and establish clear, shared ways of working across teams.
• Combine workflows in one central platform — the piece cites tools like Quickbase, which remove the need to switch between systems because everyone works in one place.
• Require each tool to have a clear, direct functional purpose before it enters the stack, and retire what serves none.

A smaller set of shared tools, supported by common processes and standards, outperforms multiple disconnected systems: it gives teams a shared way of working and keeps data and workflows consistent.

What is the actual equation?

Technology remains essential for modern operations teams — the problem is adding tools without considering how they fit the wider operational environment. Tools are only part of the equation; teams also need the skills, shared standards, and confidence to use technology effectively.

The piece closes on a plain formulation: stronger teams don't necessarily need more software. They need the right tools, the right skills, and a consistent way of working. For organizations already past 300 apps, that argument suggests the next budget cycle should fund consolidation and training rather than another platform.