What to rip out of your B2B SaaS tech stack before you buy anything else

Something in your go-to-market is not working. Leads are not converting, or reporting takes half a day, or three people have three different numbers for the same thing.

So you go looking for a tool. There is always a tool.

I understand the instinct completely. Buying something feels like progress in a way that sitting with the problem does not. You can put it in a board update. You can tell the team you have addressed it.

It is also how a B2B SaaS tech stack ends up where yours probably is. Companies between 50 and 500 employees now run an average of 16.3 mission-critical SaaS applications, up from 11.2 in 2021. Only 37% have any formal process for reviewing whether they still need them.

So things arrive and nothing leaves. Every tool was bought for a reason that made sense at the time, and nobody is responsible for noticing when the reason stops applying.

Is shadow IT really where your SaaS waste is?

No, and I think this is the most useful thing in this post.

When people decide to get serious about tool sprawl, they go hunting for shadow IT. The subscription someone expensed. The trial that quietly became a paid plan. The tool a team started using without telling anyone.

It feels like the problem because it is the part nobody controlled. There is also something satisfying about finding it.

Zylo’s 2026 data puts shadow IT at 34% of the average SaaS portfolio and about 4% of the spend.

A third of your apps. A twenty-fifth of your money. You can spend a week tracking all of it down and recover almost nothing.

The money is in the tools you approved. Bought deliberately, renewed automatically, used by three people out of twenty. Flexera found 68% of IT leaders admit at least 22% of their licences are inactive or underutilised, and that is the sanctioned portfolio, not the rogue one.

That is a harder conversation to have, because somebody in the room signed off on each of them. Usually you. Which is probably why most teams go looking for shadow IT instead.

What should a B2B SaaS team remove first?

Four categories, each with a test you can apply this week.

1. Tools where only one person knows how it works

If a tool has a single owner and that person is the only one who opens it, you are not running a system. You are subsidising somebody’s preference.

It is also a continuity risk. When they leave, nobody can explain what it does, so it renews forever because cancelling feels dangerous. I have seen this with reporting tools in particular. One person built something in it, left, and the subscription outlived them by years.

Test: could somebody else pick it up next week using only what is written down?

2. Anything holding a second copy of data you already have

This is the expensive one, and the cost is not the licence.

When your CRM, your marketing platform and somebody’s spreadsheet all hold pipeline data, and nobody has declared which one wins, every meeting starts by reconciling numbers instead of making decisions. For a B2B SaaS team that is a tax on every forecast conversation you have.

We went into what that does to pipeline specifically in the CRM hygiene post.

Test: when two systems disagree, is there a written answer about which is right? If not, you have a source-of-truth problem and no tool fixes it.

3. Tools bought for a problem you no longer have

Stacks accumulate in layers. You bought something at eight people because onboarding was chaotic. You are forty now with an actual process, and it still renews every January.

Nobody cancels it because nobody is sure what it is doing, and it is only a few hundred a month.

Test: can you name the specific problem it was bought for, and is that still your problem?

4. The second tool doing the first tool’s job

This usually arrives when one team finds the shared tool awkward and buys their own. Now two tools do the same job, neither of them fully, and your data lives in both.

BetterCloud found 63% of organisations consolidate specifically because of overlapping or underused apps. It is the single most common trigger.

Test: list your tools by job rather than by vendor. The duplicates become obvious in about ten minutes.

What should you not cut?

Subtraction has its own failure mode, and I would rather you did not learn it the hard way.

Do not cut on price alone. The cheap tools are often the ones doing real work. The expensive one nobody questions is usually the problem.

Do not cut because usage looks low. A tool opened twice a quarter for reporting that matters is fine. Usage tells you frequency, not value.

Do not consolidate into a platform you have not tested properly. “One tool to replace four” is the oldest pitch in software. Sometimes it is true. Often you end up with one tool doing four jobs adequately and none of them well, plus a migration you did not budget for.

Do not cut anything during a quarter that depends on it. Obvious, routinely ignored.

How do you audit a B2B SaaS tech stack?

Removal is the second step, not the first. The order matters more than people expect.

1. Write down what you are actually trying to achieve. Not “better reporting”. The number the business is accountable to. Without that, every tool looks defensible, because every tool does something.
2. Map tools to jobs, not to teams. One line each: what job does this do, who owns it, what breaks if it disappears on Friday. The ones where nobody can answer the third question are your candidates.
3. Decide your source of truth. For contacts, for pipeline, for revenue. One system per thing, written down. This matters more than any removal you make.
4. Then remove. One at a time, with somebody watching what breaks.
5. Then, and only then, consider adding. If the problem survives a clean stack with agreed data, it is a real gap and worth buying for. In my experience most of them do not survive.

Why is stack sprawl a GTM problem, not an IT one?

Because of who bought the tools.

81% of SaaS spend is now controlled by business units rather than IT. In a B2B SaaS company that means sales, marketing and customer success each bought their own things to solve their own problems.

Which tells you the mess is a symptom rather than the disease. Three teams, three sets of tools, three versions of the number, because the three functions are being run as separate problems instead of one engine. We set out what that looks like across the whole motion in our GTM strategy guide.

A tidy stack is what happens after you agree what you are measuring. I have not often seen it happen the other way round.

Common questions