The Cut List: How to Survive SaaS Consolidation

· 26 min read

A buyer I have known for years told me last month that his first act as the new VP of operations was to open a spreadsheet, list every piece of software his company paid for, and sort it into two columns. One column was the stuff the business would stop working without. The other column was everything else. He had been given a number from finance: cut it by a fifth. He was not asking which tools were good. He already knew most of them were fine. He was asking which ones he could live without.

That spreadsheet is the thing I want you to understand, because a version of it now exists inside almost every company you are trying to sell to. Gartner reports that 68% of CIOs rank vendor consolidation as a top-three priority, with a stated target of cutting their vendor count by roughly 20% inside twelve months. Zylo’s 2026 SaaS Management Index puts the average enterprise at about 312 software applications, up from around 200 four years earlier, with 46% of them underused or dormant and roughly 21 million dollars a year spent on licenses nobody opens. The most-expensed application in that index is now ChatGPT, which tells you where the new budget went and where the old budget is being clawed back from.

So the market is subtracting. For a decade software sold itself on the promise that you could assemble a best-of-breed stack, one sharp tool for each job, and the tools would talk to each other. That decade is over. The people who buy software are tired of logging into 300 things, and finance has handed them a knife. If you are building a company right now, the most useful question is not whether your product is better than the alternatives. It is whether, when that spreadsheet opens, you land in the column the buyer protects or the column the buyer cuts.

I have been on both sides of this. I have built products that got kept through three rounds of belt-tightening, and I have built one that got cut in a consolidation I did not see coming, by a customer who liked us, for reasons that had almost nothing to do with the quality of what we made. The second one taught me more. Here is what I wish I had known going in.

Buyers stopped adding software and started subtracting it

For most of the SaaS era, the growth model assumed addition. A new category appeared, a few companies raced to define it, buyers tried one, and the install base compounded. Net revenue retention above 120% was normal because accounts expanded on their own. You could build a real business by being the best answer to a narrow question, and the market would keep handing you new accounts because the total number of tools per company kept climbing.

The direction reversed. The same Zylo index that counts 312 apps also counts 46% of them idle, and that gap is what finance now attacks every renewal cycle. When a budget owner has 140 unused licenses sitting on the books, the fastest win available to them is not negotiating a better rate. It is killing the subscription. A dollar saved by cancellation shows up immediately and does not require anyone to change how they work, as long as the tool was not load-bearing. That last clause is the whole game.

I want to be careful not to overclaim here, because consolidation waves are partly cyclical. Money got expensive, boards asked for efficiency, and software was an obvious place to find it. Some of this reverses when capital loosens again. But the structural piece does not reverse, and the structural piece is new: for the first time, the platforms your customers already pay for can absorb what your product does, cheaply, using the same AI that made everything cheap to build. That changes consolidation from a budget mood into a standing threat. The mood passes. The threat does not.

I wrote earlier about the weekend clone, the way cheap models let your own customer rebuild a rough copy of your product themselves. The cut list is the sibling problem, and it is worse in one specific way. The weekend clone needs the buyer to do something. The cut list needs the buyer to do nothing. They do not have to build anything or switch anything. They just have to not renew.

Usage is not the same as safety

The most dangerous belief a founder can hold in a consolidation year is that happy users mean a safe account. I held it. We had a product people genuinely liked, with a Slack channel full of champions who would have fought for us in a survey. We still got cut. The decision was made two levels above our champions by someone who had never logged in and never would, looking at a line on a spreadsheet, asking a single question: if this went away, who screams, and how loud.

Not loud enough, it turned out. Our champions liked us the way you like a good restaurant you go to twice a year. They would miss us. They would not quit over us. And the tool next to us on the list, which almost nobody praised, was wired into the payroll run, so cutting it would have broken something on the fifteenth of the month. Guess which one survived.

This is the uncomfortable truth underneath all the consolidation data. The cull does not target the worst products. It targets the most droppable ones. Droppability and quality are different axes, and in a cutting year droppability is the only one that gets measured. A beloved tool that touches nothing essential is more exposed than a mediocre tool that sits in the middle of a workflow the company cannot pause. If you have been optimizing for how much your users like you, you have been measuring the wrong thing. You should be measuring how much breaks when you leave.

Every buyer keeps two lists, and your product is on one of them

Here is the frame I use now, and the only named idea in this piece. Every buyer, whether they write it down or not, keeps two lists. There is a keep list of vendors that are load-bearing, the ones that would break the business or break someone’s month if they disappeared. And there is a cut list of everything else, the vendors that are useful, even liked, but survivable to lose. Consolidation is just the moment the cut list gets acted on. Your product sits on exactly one of these lists inside every account you have, and most founders have no idea which.

The sorting happens at what I think of as a consolidation gate. Once a year, usually at renewal or during a finance-led review, the buyer’s whole stack gets run through it. A few tests decide which side you come out on. Do people actually use it. Does a platform we already pay for now do roughly the same thing. How hard would it be to rip out. Does losing it break a workflow, lose data we need, or leave a job with no owner. The tools that pass come out on the keep list. The tools that fail come out on the cut list, and the cut list is where renewals go to die.

The consolidation gateEvery renewal cycle, the whole stack gets sorted into two listsThe stack~312 appspayrollCRM of recordliked but idle tooloverlaps the suiteone-integration add-onconsolidationgateuse / overlap / rip cost /breaks-on-exitKeep listsystem of recordbreaks a workflow if goneholds data you causeowns an outcomeCut listlow or vanity usagesuite does it nowcheap to rip outnice to haveThe test is not “is it good.” The test is “what breaks if it leaves.”

Once you see the two lists, a lot of product decisions get simpler. Every feature, every integration, every onboarding choice is really a vote for which list you end up on. You are either accumulating reasons you are load-bearing, or you are accumulating reasons you are pleasant and optional. The founders who survive consolidation are the ones who made that a design goal on purpose, early, before anyone was cutting.

The cull runs on two pressures, not one

It would be easy to say consolidation is just about money, and leave it there. It is not, and the difference matters for how you defend yourself. Two separate pressures push a product toward the cut list, and they require different responses.

The first is the budget knife. Finance wants fewer line items, lower total spend, and a shorter vendor list to manage, because every vendor carries hidden cost beyond the subscription: the security review, the integration maintenance, the single sign-on seat, the renewal negotiation, the one more login. Industry estimates put as much as 30% of IT budgets into integrating and maintaining tools that were each sold as a time-saver. The knife does not care whether you are good. It cares that you are a separate contract.

The second pressure is the platform’s reach, and this is the one that changed. For years, the big suites could not actually do what the sharp point solutions did. The point solution was better, and better was enough to justify a separate line item. Now the suites ship a passable version of your feature out of the box. Salesforce bundles agent capability into its platform. HubSpot does the same. Analysts estimate platform AI can now cover something like a quarter to a third of what standalone point solutions used to sell, and the companies that consolidate onto those suites report cutting their stacks by a large chunk while taking real cost out. The buyer does not need your product to be beaten. They need it to be close enough that the convenience of one fewer vendor wins.

These two pressures stack. The platform makes it technically possible to drop you, and the budget knife makes it urgent. When both line up on the same tool in the same quarter, that tool is gone, and the quality of your product never entered the conversation.

From unbundling to rebundlingapps per companypeak ~202220122026Unbundling: best-of-breed, add a tool per jobRebundling: suites + AI absorb, cut the list~200 → ~312 then falling46% idle gets culled first

I find it useful to hold the two eras side by side, because the buyer’s logic is genuinely different in each, and a lot of founder advice is still written for the era that ended.

What the buyer does Unbundling era (2012–2022) Rebundling era (now)
Default move Add the best tool for the job Remove anything the suite can cover
What wins a deal Being clearly better at one thing Being impossible to remove without pain
Who decides The team that uses it Finance and a platform owner, above the users
What dies Tools that are worse Tools that are droppable, good or not
Your job as founder Win the category Become load-bearing in a workflow

AI moved the absorb button to the platform’s side of the table

The reason this feels sudden is that building a feature used to be slow and expensive, which protected point solutions. A suite could announce it wanted to compete with you and still take two years and a dozen engineers to ship something half as good. That lag was your protection even if you never named it. The lag is mostly gone. At its 2026 developer day, OpenAI priced its mid-tier model at roughly a fifth of the prior generation, and the whole industry’s cost of generating working software fell with it. When the cost of building a feature collapses, the cost of absorbing yours collapses too.

So the platform that owns the buyer’s core workflow can now ship a close-enough version of what you sell on a quarterly cadence, from parts it already owns, aimed at users it already has. I called this dynamic the commoditization clock when the one doing the absorbing was the frontier model itself. The cut list is the same clock, but the hand on it is the incumbent suite your customer already logs into every morning, and it moves faster because the suite does not have to be excellent. It only has to be present and good enough to make one more vendor look like waste.

Microsoft gave the clean example when it wound down Viva Goals, a standalone goals-and-OKR tool it had folded into its own stack. If a platform will retire a tool it owns once the capability lives inside the suite, imagine how it treats a tool it does not own that sits in the same lane. The pattern repeats across categories: a function that was a company becomes a feature inside something bigger, and the standalone version gets cut at the next renewal. This is the thin end of the wrapper trap, but it reaches well past thin wrappers. Real products with real teams get absorbed too, if what they do maps cleanly onto something the platform can now generate.

The data from the buyer’s side confirms the direction. In Retool’s 2026 survey of software teams, about a third said they had already replaced a paid SaaS tool with something they built themselves, and a similar share said they had stopped buying a tool they would have purchased a year earlier. Those are not hypothetical future cuts. They are cuts that already happened, made easier by the same cheap generation that lets a platform ship your feature. When your customer and your customer’s platform can both produce a workable version of what you sell, the standalone product gets squeezed from two directions at once.

There is one consistent escape from that squeeze, and the numbers around vertical software show it. Generic, horizontal tools that sit lightly across many industries churn at something like 15% a year, while software built deep into a single industry’s workflow churns in the low single digits and often carries a large price premium, because what it does is not a feature a general platform wants to own. The lesson is not that going vertical is magic. It is that absorption avoids depth. A platform will happily ship the shallow, general version of your feature and has no appetite for the messy, regulated, industry-specific guts of a workflow it does not understand. Depth is the place the absorb button stops working.

The honest version of this is that most single-feature products are now living on borrowed time, and the length of the loan depends on one thing: how close what you do sits to something a big platform already does. The closer you are, the shorter the loan.

The question is not whether you are good, it is whether you are droppable

So the test I run on my own products now, and the one I would run on yours, has nothing to do with how good the product is. It has two axes. One is how deep you sit in the buyer’s workflow, from a shallow tool they could route around in an afternoon to a system of record the business genuinely runs on. The other is how substitutable you are by a platform they already pay for, from trivially absorbed to structurally out of reach. Plot yourself honestly on both and you know which list you are on.

The keep testDepth in the workflow →shallow / optional …………….. load-bearing / system of record↑ Out of reach of the platformDefensible but fragilehard to copy, easy to skiploved, not load-bearingUn-cuttable ★runs a workflowplatform can’t absorb itremoving it breaks thingsCut firstshallow and absorbablea feature, not a companyBorrowed timedeep today, absorbable soonrace to get un-copyable

Most founders want to believe they are in the top-right box. Almost nobody starts there. You usually start in the bottom-left, as a sharp little feature that is both shallow and easy to copy, and the work of building a durable company is the slow climb up and to the right, earning depth and earning distance from the platform one release at a time. The products that get kept are the ones that made that climb before the cutting started. The table below is the version of the keep test I actually use, because the axes are easier to reason about as concrete signals.

Signal Lands you on the cut list Lands you on the keep list
Usage Opened occasionally, by a few fans Used daily inside a required process
Overlap with the suite The platform now does a close version The platform cannot do it from its own parts
Cost to remove One integration, unplug in an afternoon Wired through many systems and people
Data Holds data they could export and forget Holds the data the business is generated by
Accountability Helps with a task someone else owns Owns an outcome with your name on it

Here is the test running in real life. Picture two tools in the same stack. One is a polished analytics dashboard that a few managers open on Monday mornings to admire a chart. It looks better than anything the suite offers, and everyone agrees it is nice. The other is a dull approvals tool that sits in the middle of how purchase orders get signed, holds the record of who approved what, and would leave a legal gap if it vanished. In a bake-off on quality, the dashboard wins easily. On the cut list, the dashboard is gone by lunch and the approvals tool is untouchable, because one is admired and the other is load-bearing. If you cannot say in one sentence what concretely breaks when you leave, you are the dashboard.

A worse feature inside the suite beats a better product outside it

This is the part founders resist hardest, so let me say it plainly. In a consolidation year, a worse feature living inside a platform the buyer already pays for will beat a better standalone product, and it will beat it badly. Quality is not the deciding variable. Vendor count is. The buyer is not running a bake-off between your product and the suite’s feature. They are answering a different question, which is whether keeping you is worth one more contract, one more login, one more security review, and one more renewal to negotiate. Against that question, better is often not enough.

I learned this the expensive way. The product we got cut was, by any fair comparison, clearly better than the suite feature that replaced it. We benchmarked it after the fact out of wounded pride, and we were right, we were better. It did not matter even slightly. The buyer had a mandate to reduce vendor count, the suite feature was already paid for, and switching to it cost them nothing but a mild downgrade nobody above the users would ever feel. Being right about quality while losing on droppability is the most frustrating way to lose, because every instinct tells you to respond by making the product even better, which does nothing.

The asymmetry is worth sitting with, because it is brutal. To win a new account you have to be meaningfully better, since the buyer has to be talked into adding you. To lose an existing account you only have to be replaceable, since the buyer is already hunting for someone to remove and you are a candidate on a list. Better earns you the deal once. Hard to drop keeps you through every budget review that comes after. Founders pour almost everything into the first and almost nothing into the second, then act surprised when a renewal they were sure was safe quietly fails to close.

The correct response is almost the opposite of what pride demands. You do not win the account back by being more impressive. You win it, or keep it, by being more entangled. The verification ceiling argument applies here in a slanted way: buyers in a cutting year are not short on options, they are short on the attention to evaluate options, so they default to removing the thing that is easiest to remove. Make yourself the thing that is hardest to remove and you often never even reach the bake-off.

How to climb off the cut list

So how do you actually become load-bearing instead of pleasant. There is no trick, but there are a handful of moves that reliably move a product up and to the right, and I have watched each of them save an account.

The first is to become the system of record for one workflow, not a helper beside it. A helper improves a process that lives somewhere else, which means the process survives your removal. A system of record is the place the work actually happens and the truth actually lives, which means removing you means rebuilding the workflow from nothing. Pick one workflow you can own end to end and own it completely, rather than being a nice layer on five workflows you touch lightly. Depth in one place beats presence in many, and this is the same lesson I keep landing on with the incompressible core: the part of a business that cannot be compressed away is the part that does something load-bearing, not the part that is merely useful.

The second is to hold data the business is generated by, not data it could export and forget. There is a real difference between storing a copy of information that exists elsewhere and being the origin of information nothing else has. If the history, the context, and the accumulated state of a workflow live only inside you, and they got there through months of real use, then removing you does not just remove a tool, it removes a memory the company cannot reconstruct. That is the difference between a cut that costs an afternoon and a cut nobody is willing to sign off on.

The third is to own an outcome with a name on it, not a task. Tasks get absorbed because a platform can do the task too. Outcomes resist absorption because an outcome comes with accountability, and accountability does not live inside a feature. If someone at the buyer can say that a specific number is your responsibility, that compliance holds because of you, that a result ships because you make it ship, then cutting you is not a line-item decision anymore. It is someone volunteering to own a risk they had been happily handing to you.

There is a fourth move that is more aggressive and not for everyone: be the consolidator rather than the consolidated. If buyers want fewer vendors, the winning position is to be the vendor that absorbs the jobs of the three tools around you, so that you are the thing the stack collapses onto instead of the thing that gets collapsed away. This is how a point solution becomes a platform, and it is the most durable answer to rebundling, but it is also a different company than the one most founders set out to build, and pretending otherwise is how you end up doing everything adequately and nothing in a way that is load-bearing. I would rather own one workflow so completely that I cannot be cut than own ten shallowly and be droppable in all of them. The build-versus-absorb decision underneath all of this is the same one I worked through in build versus buy, just seen from the seller’s chair.

Price like a line item that survives the audit

Pricing deserves its own moment, because the way most software is priced is now actively dangerous. Per-seat pricing was built for the unbundling era, when adding seats signaled growth. In a consolidation year, a per-seat contract is a gift to the person running the license audit. They open the usage report, see that you sold 400 seats and 180 get used, and you have handed them both the justification and the savings in one screen. Zylo’s 46% idle figure is not an abstraction to that person. It is their quota. Per-seat pricing turns your own low adoption into the exact evidence used to cut you.

The fix is to price against the value you create, not the number of logins you occupy, which is the same argument I made about pricing under cheap inference, now with sharper teeth. If your price is tied to an outcome the buyer cares about, a transaction processed, a deal closed, a result delivered, then cutting you means cutting the outcome, and the usage report stops being a weapon. You want the renewal conversation to be about what the business loses, not about how many seats sat idle. Price is not just how you capture value. In a cutting year, price is part of whether you are cuttable at all.

I will be honest that outcome pricing is harder to sell and harder to forecast, and some categories genuinely do not support it. But the direction is right even when the pure form is not available. Anything that moves your contract away from a countable idle-seat metric and toward a value the buyer would miss makes you harder to cut. The switching cost you build should be a cost of losing something real, not a cost of your contract being annoying to exit, because the second kind breeds resentment and the first kind breeds renewals.

A 30-day audit to find out if you are on the cut list

None of this helps unless you can see your own exposure before a buyer acts on it, so here is the audit I run, and it takes about a month because the honest answers are slow to gather.

In the first week, pick your ten largest accounts and answer one question for each without flattering yourself: if this customer had to cut a fifth of their software next quarter, are we above the line or below it. Do not ask your champions, who will tell you that you are safe. Ask what would actually break if you vanished, and whether anyone above your users would feel it. If you cannot name the thing that breaks, you are below the line, and you now know it before finance does.

In the second week, map your overlap with the platforms your customers already pay for. For each big account, write down the suite at the center of their stack and ask what fraction of what you do that suite could now do passably. If the honest answer is a lot, your absorption clock is running fast, and the rest of this audit is urgent rather than theoretical. This is also where you find out whether you are living in the shadow of the capability overhang, selling something the platform has already quietly become able to ship.

In the third week, pick the single workflow where you are closest to being a system of record, and decide to own it completely. Find the gap between where you sit and where the truth of that workflow actually lives, and close it. This is the one move with the highest return, because depth in one workflow is what converts a liked tool into an un-cuttable one, and it is almost always under-invested relative to the feature breadth founders chase instead.

In the last week, look at your pricing and your data position with the audit in mind. Is your contract structured so that your own idle usage can be used against you, and would a cut remove data the customer cannot get back. Fix the first by moving price toward value, and deepen the second on purpose, so that leaving you costs the buyer something they would rather not pay. By the end of the month you will have a blunt, account-by-account picture of where you are droppable, which is worth more than any survey of how much your users like you.

The whole thing fits in the larger argument I keep returning to in the AI-native founder playbook: when building gets cheap, the scarce and defensible things are the ones that are not about building at all. Being load-bearing is one of them. It is earned slowly, it does not show up in a demo, and it is the difference between a product a buyer keeps through a hard year and a product a buyer liked right up until the spreadsheet opened.

Questions founders ask

What is SaaS consolidation, and why is it accelerating now?

SaaS consolidation is a buyer cutting the number of software vendors they pay for, usually by moving overlapping jobs onto a smaller set of platforms. It is accelerating for two reasons at once. Finance wants fewer contracts and less waste, with surveys showing most CIOs targeting roughly 20% fewer vendors, and the average company carrying hundreds of apps with nearly half of them idle. And platform AI now lets the big suites cover a meaningful share of what point solutions used to do, which makes dropping a separate vendor feel like removing waste rather than losing a capability.

How do I know if my product is on a customer’s cut list?

Ask what breaks if you disappear, and ask it about the people above your users, not your champions. If the honest answer is that a few fans would be mildly annoyed, you are on the cut list. If the answer is that a required workflow stops, a number loses its owner, or data the company needs becomes unreachable, you are on the keep list. Low daily usage, heavy overlap with a platform they already pay for, and a one-integration setup that unplugs in an afternoon are the three clearest warning signs.

Does being better than the alternative protect me?

Not much, in a cutting year. The decision is usually made above the users by someone comparing vendor count and spend, not features. A worse capability inside a suite the buyer already pays for routinely beats a better standalone product, because keeping you costs another contract and another security review, while the suite feature costs nothing new. Quality matters for winning new categories. Droppability decides who survives consolidation.

Is this just a temporary, budget-driven cycle?

Part of it is cyclical and will ease when capital gets cheaper, so some accounts come back. But the structural piece does not reverse. For the first time, the platforms your customers already use can absorb what you do cheaply, using the same AI that collapsed build costs. That turns consolidation from a passing budget mood into a standing pressure, so treating it as a cycle to wait out is a mistake.

What is the single highest-return move to avoid being cut?

Become the system of record for one workflow instead of a helper beside several. A helper improves a process that lives elsewhere and survives your removal. A system of record is where the work happens and the truth lives, so removing you means rebuilding the workflow from nothing. Depth in one place beats breadth across many, and it is the move most founders under-invest in because feature breadth is more fun to build.

Should I change my pricing because of consolidation?

If you price per seat, you have handed the license auditor the exact report they need to cut you, because your idle seats are their savings. Move price toward a value or outcome the buyer would miss if you left, so that cutting you means cutting a result rather than trimming unused licenses. Outcome pricing is harder to sell and forecast, but any shift away from a countable idle-seat metric makes you harder to drop.

Can a small startup really become un-cuttable against a big platform?

It is possible, but only by going deep, not wide. You will not out-feature a suite, and you should not try. You become un-cuttable by owning one workflow so completely that the business runs on you, holding data the company is generated by, and taking accountability for an outcome a feature cannot own. A small company can be load-bearing in a narrow place even when it could never match the platform’s breadth, and narrow and load-bearing beats broad and optional every time a stack gets cut.

What if the platform just absorbs my whole category?

If your entire category maps cleanly onto something a platform can now generate, you are on borrowed time, and the honest move is to change what you are before the renewal does it for you. Either go deeper into a workflow the platform does not want to own, or become the consolidator that absorbs the tools around you so the stack collapses onto you instead of away from you. Staying a single shallow feature next to a suite that can ship your feature is the one position with no good ending.

I am a four-time founder building AI-native companies. I write about the founder mindset, AI opportunities, and the mechanics of building with AI at vikasmalpani.com.