Your SaaS Stack Is a Liability, Not an Asset
You're paying for 47 tools and none of them talk to each other. SaaS sprawl is silently killing your productivity, your budget, and your ability to move fast. Here's how to fix it.
The average mid-size company uses somewhere between 80 and 130 SaaS tools. Nobody knows the exact number because nobody can count them all. That alone should tell you something.
Every quarter, someone on your team signs up for a new tool. It solves one specific problem beautifully. It gets adopted by three people. It never integrates with anything else. Six months later, it’s a zombie subscription nobody cancels because nobody remembers who owns it.
This isn’t a procurement failure. It’s a strategy failure. And it’s costing you far more than the subscription fees.
The real cost isn’t the invoices
When people talk about SaaS sprawl, they focus on spend. “We’re paying $200K a year on tools.” Sure, that’s real money. But it’s the small part of the problem.
The bigger costs are invisible:
Context switching. Your team lives in Slack, then jumps to Notion, then checks Jira, then updates a Google Sheet that feeds a dashboard in Looker that nobody trusts because the data is three hours stale. Every tool switch costs 10-15 minutes of cognitive recovery. Multiply that across a team of 20 people and you’re burning hundreds of hours per month on tool transitions alone.
Integration tax. Nothing talks to anything natively. So you build Zapier workflows. Then the Zapier workflows break. Then someone builds a custom integration. Then that person leaves. Now you have a critical business process running on a Lambda function nobody understands, triggered by a webhook nobody monitors.
Data fragmentation. Your customer data lives in Salesforce, HubSpot, Intercom, Stripe, your product database, and a Google Sheet that the sales team maintains “just in case.” Which one is the source of truth? All of them. None of them. Depends on who you ask.
Vendor lock-in by accumulation. No single tool locks you in. But 80 tools collectively do. Migrating one is manageable. Migrating your entire operational stack is a multi-year project. So you don’t. And the tools know that.
How you got here
Nobody sets out to build a Frankenstein stack. It happens gradually, and it happens for understandable reasons.
Speed over architecture. When you’re moving fast, “just sign up for this tool” is the rational choice. Building custom takes weeks. Signing up takes minutes. At any individual decision point, the SaaS option wins.
Department-level decisions. Marketing picks their tools. Sales picks theirs. Engineering picks theirs. Nobody’s looking at the whole picture because nobody owns the whole picture.
The demo trap. SaaS demos are optimised for a single moment: the “wow, this is easy” reaction. They’re not optimised for “how does this work when 50 people use it alongside 30 other tools?” That question doesn’t come up until month four.
Fear of commitment. Building a custom internal tool feels permanent and expensive. A SaaS subscription feels reversible. “We can always cancel.” Except you won’t, because switching costs are real and growing.
The consolidation playbook
The fix isn’t “cancel everything and build it all custom.” That’s the other extreme and it’s equally stupid. The fix is being intentional about what deserves to be a tool, what deserves to be a platform, and what deserves to be your own.
Audit ruthlessly
Start with a full inventory. Not just what’s in your billing system - check expense reports, credit cards, and browser extensions. You’ll find tools you forgot existed.
For each tool, answer three questions: How many people actively use it? What breaks if it disappears? Is the data it holds available anywhere else?
Anything used by fewer than three people that doesn’t hold unique data is a candidate for immediate elimination.
Identify your core platforms
Every company needs three to five core platforms. Everything else should integrate with those or not exist. For most companies, this looks something like: a communication hub, a project/work management system, a CRM or customer data platform, a codebase and deployment pipeline, and a data warehouse.
Pick these deliberately. Make them official. Everything else is a satellite that must justify its existence by how well it connects to the core.
Build the glue, not the tools
Here’s where most companies get it backwards. They buy tools and then try to glue them together. Instead, invest in the glue layer first.
A lightweight internal integration layer - whether that’s a proper data pipeline, a well-maintained API gateway, or even a set of standardised webhooks - pays for itself within months. When your systems actually share data reliably, you stop needing half the point solutions you bought to work around the fact that they didn’t.
This is something we see constantly at IndieStudio. Companies come to us wanting to build a new tool when what they actually need is a thin integration layer connecting what they already have. The right custom middleware often replaces three or four SaaS subscriptions and actually works better because it’s built for your specific workflow.
Set a procurement bar
New tools should clear a higher bar than “it’s cool and has a free tier.” Before adding anything to the stack, require answers to: Does this integrate natively with our core platforms? Who owns it? What’s the exit strategy if we need to leave? Does it replace something we already have?
That last question is the killer. In most companies, new tools don’t replace old ones. They stack on top. The old tool doesn’t get cancelled because three people still use one feature. So now you have two tools doing 80% of the same job.
When to build custom
The right time to build a custom internal tool is when your workflow is genuinely unique and no SaaS product maps to it without heavy customisation, or when you’re spending more on integration workarounds than a purpose-built solution would cost.
The wrong time is when you’re just frustrated with your current tool and think building your own will be simpler. It won’t be. Building software is hard. Maintaining software is harder.
The sweet spot is usually internal operations tools - the stuff that connects your business processes in ways no vendor anticipated because the vendor built for the general case, not your specific one. Custom dashboards, workflow automation, data pipelines, internal APIs that unify your customer data. These aren’t products. They’re plumbing. And good plumbing is worth investing in.
The uncomfortable truth
Your SaaS stack grew because making small decisions is easier than making big ones. Every individual subscription was reasonable. The aggregate is not.
Fixing it requires someone to own the whole picture, make uncomfortable decisions about consolidation, and invest in the boring infrastructure work that makes everything else run smoothly.
It’s not glamorous work. But the companies that move fastest aren’t the ones with the most tools. They’re the ones with the fewest tools that actually work together.
Stop collecting SaaS subscriptions. Start building a system.