A Typical US Company Runs 35 Paid Tools. Somehow, It Still Needs a Spreadsheet.
The answer is not to replace every SaaS tool or build a private replica of your stack. Keep commodity tools where they are good, then own the thin connective layer that controls shared data, reconciliation, approvals, exceptions and exit paths.
By Reynier RiveroSoftware engineer
At 9:07 on a Monday, an operations lead opened the renewal spreadsheet and searched for “customer status.”
This is a composite scene, not a reported customer anecdote.
The company had a CRM, a support platform, a project tracker, a billing system, a form builder, a warehouse, a marketing platform and several tools that had arrived through individual team decisions. The spreadsheet had one column for each system, one column for the person who supposedly owned it, and one column labelled “final answer.”
Nobody could agree which system was authoritative. Sales trusted the CRM. Finance trusted billing. Support trusted the ticket history. Operations trusted the spreadsheet because it was the only place where the contradictions were visible at the same time.
It represents a common operating pattern: specialized tools doing their local jobs while the business invents a manual control layer above them.
The spreadsheet did not exist because the company loved spreadsheets. It existed because every tool optimized a task, but nobody designed the space between the tasks.
That is the contradiction in SaaS sprawl. Software removes manual work inside departments while creating manual coordination across departments.
The tool count is a signal, not a diagnosis
Cledara’s SaaS Spend Index was updated on 17 September 2026. It uses anonymized company payments processed through Cledara rather than surveys or list prices, and reports that a typical US company runs 35 paid tools, with the middle half between 23 and 53; median annual software spend is $145,000, with the middle half between $61,000 and $350,000. Cledara’s SaaS Spend Index
This is vendor-owned payment data, not a census. It does not measure spreadsheet use, duplicate tools, unused licenses or ROI. Cledara’s methodology and scope
The number is a signal of portfolio scale, not a diagnosis. This is a portfolio problem, not only an AI-agent problem: it appears in CRM, billing, support and finance workflows even when no model is involved.
Keep the tools. Own the seams.
The first move is to classify each tool by the job it performs.
A CRM can remain the best place for sales activity. A billing platform can remain the best place for invoices. A support system can remain the best place for tickets. The mistake is expecting any of them to become the company’s complete operating model simply because it has an integration marketplace.
A practical architecture has four layers:
The commodity layer
Keep specialized SaaS where it provides real leverage and the cost of replacing it would exceed the value of owning an equivalent product.
That includes mature capabilities such as email delivery, payroll, accounting, ticketing, project management and standard customer relationship management. Rebuilding a commodity tool to avoid every dependency can simply move the dependency to your own team, with less mature tooling.
The connective layer
Build a thin layer that owns the shared rules between tools.
If the tools share little data and no recurring decision crosses them, do not build a connective layer for the sake of symmetry. A native integration or a controlled export may be enough.
It should define canonical identifiers for customers, accounts, invoices, orders, subscriptions and cases. It should translate fields between systems, manage queues and retries, enforce idempotent writes, record audit events and expose reconciliation results.
It should not become a second CRM. It should answer questions such as:
- Which customer does this payment belong to?
- Which invoice status is authoritative?
- What happens when the customer exists in one system but not another?
- Who approves a refund, account merge or access change?
The connective layer is where the cross-system rules live. The SaaS tools remain bounded components around it, with their data, ownership and exit paths made explicit.
The exception layer
Integrations are usually designed around the happy path. Spreadsheets appear when the unhappy path has nowhere else to go.
A missing customer ID, conflicting subscription state, failed webhook, duplicate account or unmatched payment should create a visible exception with an owner, timestamp, reason and next action. It should not silently overwrite the last known value or disappear into a log that nobody checks.
This is where technical details become operating discipline. Use least-privilege service accounts, scoped tool permissions, redaction for sensitive fields, approval gates for irreversible actions, structured audit logs and a retry policy that eventually moves failures into a human queue.
The goal is not to eliminate humans. It is to stop humans from becoming undocumented middleware.
The exit layer
For every important service, record what can be exported, in which format, with which identifiers and under whose control.
Keep provider-independent copies of critical business objects where appropriate. Document data mappings. Test an export before a crisis. Track contractual and technical switching costs while the architecture is still small enough to change.
The UK Government’s cloud lock-in guidance, published on 17 December 2019 and updated on 3 September 2026, describes lock-in as switching that is difficult, time-consuming and disproportionately expensive, and recommends monitoring switching costs and interoperability. The guidance on managing technical lock-in in the cloud
The UK Technology Code of Practice was published on 14 July 2021 and last updated on 7 July 2025. Its principles include open standards, reuse, integration with existing technology, better use of data and an explicit purchasing strategy. It is a government standard, not a universal private-sector rule, but the architecture principles travel well. The UK Technology Code of Practice
The spreadsheet is an architecture review
The renewal spreadsheet can be an honest diagram of a fragmented portfolio.
It shows where ownership is unclear, where the same customer is represented five different ways, where approvals happen in private messages and where a failed integration becomes somebody’s Friday afternoon.
Before approving another subscription, ask four questions:
- Which system owns each important business object?
- What happens when the sync fails?
- Which actions require human approval?
- How would we export the data and replace the tool?
If the answers live only in one person’s memory, the business does not have a tool problem. It has an architecture boundary that was never designed.
For prioritization, read how to decide what to automate first. Despite that article’s URL, the decision framework here is tool-agnostic: start with the workflow where ownership, reconciliation or exceptions create the most operational value.
When a workflow deserves ownership, custom software for workflows that deserve ownership can provide the connective layer without forcing the company to rebuild every commodity tool. The work may also begin with automation and integrations, provided the design includes data ownership, permissions, reconciliation and failure handling from the start.
Can you name the system of record for each important customer, invoice and approval—and explain what happens when the sync fails? If not, start with an architecture review before adding another tool. Prontavel can help map that boundary and build only the layer the stack is missing.
The service this article is about: Custom software and SaaS, built by a senior team