Count the logos in your accounts payable next month. Most mid-market companies that run this exercise for the first time find more than forty active software subscriptions: CRM, marketing automation, quoting, scheduling, e-signature, forms, chat, reporting, storage, and a long tail of tools someone added for a single project years ago. Each one solved a real problem on the day it was purchased. But add them up and ask a harder question, what do these forty line items contribute to the value of the business, and the answer is uncomfortable. Not one of them adds a dollar to enterprise value. Every workflow you own is an asset. Every workflow you rent is rent.
We call this the leaky bucket. Revenue comes in the top. A growing share flows straight out the bottom as subscription spend, and nothing accretes on the way through. Ten years of SaaS payments buys exactly what one month buys: permission to keep using the software for another billing cycle. The bucket never gets bigger. It just keeps leaking, and the leak widens every year at renewal.
We made the broader case for unSaaSing, replacing rented software with infrastructure you own, in an earlier article. This piece goes one level deeper on the economics: why the rented stack is worth zero at the exit table, how acquirers actually treat SaaS dependency in diligence, and what owning a workflow looks like in practice for a company that has never thought of itself as a software builder.
The Anatomy of the Leak
No individual subscription is the problem. A tool that costs $89 a month and solves a real workflow clears any reasonable approval threshold, which is exactly how the stack got built: one defensible decision at a time, by different people, over a decade. The problem is the aggregate behavior of forty of those decisions sitting on one P&L.
In the stack audits we run for mid-market companies, the same pattern shows up over and over:
- Forty-plus active subscriptions is the norm, not the exception, for companies between $5M and $50M in revenue. Most owners guess 15 to 20 before the inventory is finished, because a meaningful share of the spend hides in departmental budgets and personal cards.
- Software spend grows two to three times faster than revenue, driven by per-seat pricing, usage tiers, and renewal escalators that commonly run 8 to 15 percent a year. Add a salesperson, pay another seat. Grow the contact list, move up a tier. The stack is priced to tax your growth.
- 20 to 30 percent of the spend is overlap or shelfware: tools nobody has logged into since the champion who bought them left, or three tools doing the same job for three departments that never compared notes.
- The all-in number typically lands between 2 and 4 percent of revenue once everything is counted. On a $10M company, that is $200K to $400K a year flowing out of the bucket with nothing accreting behind it.
Those are illustrative ranges from REV Global engagements, not survey statistics, and every company's inventory reads a little differently. The pattern is what repeats: the spend is bigger than anyone thought, it grows faster than the business, and nobody is accountable for it as a whole.
But cost is the shallow version of the problem. If forty subscriptions made the company durably more valuable, the spend would be defensible at almost any level. They do not, and that is the deeper leak.
The Balance Sheet Test
Here is a simple test for any recurring expense: when the money goes out, does anything accrete? A company that spends $250K building an owned demand engine, a CRM on its own infrastructure, a unified customer database, automated follow-up running on its own rails, ends the year with an asset. The same $250K spent on subscription renewals ends the year with an obligation to spend it again.
SaaS fails the test by design, and it is worth being precise about why. Every dollar of your subscription spend is a dollar of recurring revenue on the vendor's income statement, and recurring revenue is exactly what the vendor's investors pay a premium multiple for. The equity value your spend creates is real. It just accrues to someone else's cap table. Your operating expense is, quite literally, another company's valuation story.
Meanwhile the data inside those tools, your customer records, transaction history, and pipeline, sits behind vendor APIs, rate-limited and fee-gated. You pay to generate it, then pay again to access it, and the practical consequence is that most mid-market AI initiatives stall in the integration phase because the operating data lives in eleven silos the company does not control. The path out of that trap looks a lot like the one we described in the digital transformation playbook: consolidate the data first, then automate on top of it.
The Buyer's Lens: How Acquirers Price a Rented Stack
If the balance sheet argument feels abstract, look at the same company through the eyes of the person who will one day buy it. Acquirers ask three questions about operations: what am I actually buying, what transfers on day one, and what breaks in the first year. A SaaS-dependent company gives uncomfortable answers to all three.
Nothing transfers. The tools are vendor property. The day after close, the buyer is paying the same vendors for the same rented capability, and the seller's decade of subscription fees bought no asset that shows up in the purchase price. Worse, many SaaS agreements carry assignment or change-of-control clauses, which means the transaction itself can trigger renegotiation, sometimes at pricing that reflects the vendor's leverage over a buyer who cannot operate without the tool on day one.
The data comes out hard. Buyers underwrite integration, and integration starts with data. When customer history is scattered across a dozen rented silos with API limits and export fees, the cost and time of assembling one coherent operating picture lands on the buyer's side of the model. Every hour of that work is priced somewhere, usually in the offer.
The workflows walk out the door. When a process exists as tribal knowledge stitched across eleven tools, the process is really a person. Buyers see that as key-person risk wearing a software costume, and they discount for it the same way they discount any revenue that depends on one individual staying.
To be fair to how deals actually work, no buyer reprices a target subscription by subscription. The discount shows up in aggregate: in the quality-of-earnings conversation about a cost line growing faster than revenue that management cannot control, in the integration budget, and in how much of the purchase price gets structured around risk instead of paid at close. Companies with owned, documented, transferable systems have a structurally easier conversation. It is the same logic that lets sophisticated buyers pay up for operationally improvable businesses, which we unpacked in our analysis of what bank workforce cuts signal for the middle market: buyers pay for systems that transfer and discount dependencies that do not.
What Owning the Workflow Actually Looks Like
Owning your infrastructure does not mean writing your own accounting software or hiring a development team. That version of the argument died a decade ago, and it deserved to. The version that works today has three components, and modern AI-assisted development is what changed the math on all three.
First, owned cores on open-source foundations. Mature open-source platforms now exist for every layer of the business stack: CRM, marketing automation, ERP, workflow orchestration. Deployed on your own infrastructure, customized to your process, and secured as company property, they do the job the rented tools did, with no per-seat pricing and no renewal letter. What used to take a development team and a multi-year budget is now a configuration-and-deployment exercise measured in weeks.
Second, one data layer you control. Customer records, transaction history, and pipeline consolidated into a database the company owns. This is the unglamorous step that unlocks everything else, because every AI use case, from demand forecasting to margin analysis, starts with unrestricted access to your own operating data. Companies that skip this step keep paying the API tax forever.
Third, automation on owned rails. Once the stack is unified, the highest-payback automations are the boring ones: answering inquiries in minutes instead of days, sending every follow-up on schedule, reactivating past customers nobody had time to call. This is the demand engine a rented stack structurally cannot run, because no single vendor sees the whole funnel and no vendor is accountable for your revenue. The deployment cadence looks like the one in our 100-day integration blueprint: sequenced in 30-day blocks, with the fastest-payback layer shipped first.
And some layers should stay rented. Commodity utilities with low data gravity and honest pricing, payroll and email hosting are the usual examples, are often fine as subscriptions. UnSaaSing is a portfolio decision made layer by layer with numbers, not an ideology. The goal is a bucket that holds water, not an empty toolshed.
Patching the Bucket: Where the Stack Audit Fits
You cannot patch a leak you have not located, and this is the honest reason the Stack Audit exists. It is the diagnostic, not the migration. An audit inventories every subscription and what it actually costs at renewal, maps where your demand and revenue tools drop leads, scores each layer of the stack on build-versus-rent economics, and sequences the migration starting where payback is fastest. You see the full picture, in dollars, before committing to anything.
Sometimes the audit concludes that most of a stack should stay rented for now, and that is a legitimate outcome. Even then, the company walks away with something most mid-market operators have never had: a complete inventory of what they rent, what it truly costs, and where the bucket leaks. In our experience, that document changes the next three years of software decisions on its own.
The leak does not fix itself. The renewal letters arrive every year, the per-seat charges scale with every hire, and the equity value of all of it stays exactly where it has always been: at zero. The companies that get ahead of this are not the ones with the biggest software budgets. They are the ones that stopped confusing spending on infrastructure with owning it.