In almost every service business we walk into, the first instinct, for any problem, is to buy software for it.
Project visibility is bad? Buy a PM tool. Customer follow-up is patchy? Buy a CRM. Scheduling is chaotic? Buy a dispatch system. Invoicing is slow? Buy a billing platform. Time-tracking is unreliable? Buy a tracker. Quoting takes too long? Buy a quoting tool. Documents are everywhere? Buy a document system. The team is on too many platforms? Buy a unified communication tool. Each purchase makes sense in the moment. Each one is sold as the answer. Each one gets adopted, partially, by part of the team.
Six years and twelve software purchases later, you have a tech stack of 30+ tools. Some of them overlap. Most of them don't integrate. A few are paid for and barely used. Two or three are heavily used but by different parts of the team for the same kind of work, so the data lives in three places and none of them agree. The monthly bill is somewhere between alarming and embarrassing, and you've stopped looking at it because you don't know what to do with the answer.
This article is about how to do something with the answer. How to audit what you actually have, how to identify the redundancy, and how to rationalise the stack without doing the one thing that always backfires: ripping out tools the team has finally adopted.
Why this happens
Not a moral failing. Three structural reasons.
1. The cost of any one tool is small. $40 a seat a month for a tool that seems useful is below the threshold where most owners feel the need to justify the purchase formally. Multiplied by 18 tools over four years, it's a six-figure annual line. But no single decision was big enough to flag.
2. Each department buys its own. Sales buys a CRM. Operations buys a project management tool. Finance buys billing software. HR buys an applicant tracker. Marketing buys an email platform. Each purchase is rational within the department. The problem is at the seams between departments, where the data needs to flow and doesn't.
3. Nobody owns the stack as a whole. Most service businesses don't have someone whose job it is to think about technology architecture. The IT person, if there is one, runs networks and hardware. The COO is busy. The CFO writes the cheques but doesn't shape the choices. The stack grows because nobody is responsible for shaping it.
The recognition that all three are happening at once is usually what brings owners to a Technology Stack Assessment. The fix has to address all three.
Step 1: Find out what you actually have
Almost every owner thinks they know their stack. They name nine tools off the top of their head. The actual list is usually 20+. The difference is the tools that don't go through the owner's awareness loop: free tiers somebody on the team uses, browser-based tools that don't show up as software bills, point solutions adopted by one person and never adopted by anyone else.
The audit has to be exhaustive. There's a specific order that works.
Start with the finance manager (or whoever pays the bills).
The finance person sees every recurring vendor on the credit card statement and every invoice through the AP system. Pull the last twelve months. Filter for SaaS-shaped charges: anything that recurs monthly or annually, anything with "subscription" or a tool name in the description. The list that comes back is usually surprising and almost always longer than expected. This is the financial footprint of your stack.
Then ask every team member directly.
The finance list catches what you're paying for. It misses what you're not. Free tiers of tools the team has adopted on their own. Browser extensions. AI assistants people have signed up for personally and use for work. Tools running on someone else's credit card. Tools the prior owner of a function set up and forgot about. The only way to surface these is to ask. A short questionnaire to every team member with one prompt: "List every tool you use for work, even if you don't pay for it, even if you're not sure others use it."
Reconcile the two lists.
The finance list and the team list will overlap most of the way and diverge at the edges. The divergence is the interesting part:
- Tools on the finance list but not on the team list. You're paying for software nobody's using. Usually the result of someone who's left, a license that auto-renewed, or a tool whose champion moved on. Easiest win in the assessment; cancel.
- Tools on the team list but not on the finance list. Free-tier or shadow-IT adoption. Sometimes useful and worth formalising. Sometimes a data-governance risk and worth addressing.
- Tools on both lists. The official stack. The next step deals with this group.
This step usually takes 5 to 10 days, mostly waiting on team responses. Don't skip the team-questionnaire step. It catches things the finance list never will.
Step 2: Map the tools to functions
Now you have your real list. The next step is grouping it by function, which is where the redundancy becomes visible.
Most service-business stacks cluster into roughly the same dozen functional buckets:
| Function | Typical tools | Common redundancy |
|---|---|---|
| CRM / sales pipeline | HubSpot, Pipedrive, Salesforce, Zoho | One in CRM, another in spreadsheets |
| Project management | Asana, ClickUp, Monday, Trello | Two of them, different teams |
| Field / job management | ServiceTitan, Jobber, Housecall Pro | Plus a separate scheduling tool |
| Accounting / billing | QuickBooks, Xero, Sage | Plus separate invoicing app |
| Documents / playbooks | Trainual, Whale, Notion, SharePoint | Two of them; nobody uses either fully |
| File storage | Google Drive, OneDrive, Dropbox, Box | Two or three running in parallel |
| Communication | Slack, Teams, email, WhatsApp groups | Decisions scattered across all four |
| Forms / surveys | Typeform, Jotform, Google Forms | Different forms in different tools |
| E-signature | DocuSign, HelloSign, PandaDoc | Sometimes two, by department |
| Time tracking | Harvest, Toggl, Clockify, payroll built-in | Two running, neither trusted |
| AI assistants | Claude, ChatGPT, Copilot, Gemini | Multiple, often on personal accounts |
| Marketing / email | Mailchimp, ConvertKit, ActiveCampaign | Plus separate landing-page tool |
Group your 20-30 tools by function. The redundancy will be immediately obvious. Two project-management tools. Three places for files. Four forms providers because each department picked their own. This visibility alone is usually a relief; you can finally see what you're dealing with.
Step 3: Don't shake the tree
Here's where most tech-stack rationalisations go wrong.
You have the audit. You see the redundancy. The instinct, completely understandable, is to make a decision. "We're consolidating on this tool, ripping out that one, sunsetting the other one. Migration starts next month." Everyone gets an email. The team's first reaction is mild dread.
Then reality intervenes. The "redundant" tool that's being ripped out turns out to be the one half the team has finally adopted. The "winner" tool the consolidation is converging on has features the team relies on but the alternative doesn't. The migration takes three times as long as anyone budgeted because the data structures don't translate. By the end, you've created two months of operational drag, lost some institutional knowledge that lived in the deprecated tool, and ended up with people who quietly maintain the "deprecated" tool in parallel because they can't get their actual work done in the chosen one.
Technology adoption is a real human thing. Tools that the team has built habits around (whether or not those habits are optimal) are load-bearing in a way that the spreadsheet of "which tool is technically better" cannot capture. Shaking the tree to force a consolidation almost always costs more than it saves.
The principle: change one thing at a time, in priority order, with the team's adoption as a constraint, not a footnote.
Step 4: Prioritise by financial-plus-friction impact
For each redundancy you found, score it on two dimensions:
Annual cost. What you'd save in subscription dollars by consolidating to one tool.
Friction reduction. How much daily friction the redundancy is creating. Two CRMs running in parallel produce a lot of friction (sales reps don't know where to log activity, leads fall through gaps). Two file-storage systems produce some friction (people forget which one a document is in). Two forms tools produce minimal friction (it doesn't really matter that marketing uses Typeform and HR uses Google Forms).
Plot each redundancy as cost on one axis, friction on the other. Tackle them in this order:
- High friction, high cost. The obvious wins. Do these first.
- High friction, low cost. Worth doing for productivity even if the dollar savings are small. Schedule for after the first wins land.
- Low friction, high cost. Pure financial wins. Often easiest because nobody objects. Schedule for the natural renewal date.
- Low friction, low cost. Leave alone unless you have spare bandwidth. Not worth shaking the tree.
Tackle one quadrant at a time. Don't try to do them all in a quarter. The team's adoption capacity is the binding constraint.
Step 5: For each consolidation, run a real decision
When you decide to consolidate two tools into one, the choice of which tool wins is not always obvious. Three criteria help:
Adoption depth. Which tool does the team use more deeply? Not which one has more logins. Which one has the data, the customisations, the workflows the team actually depends on? Migrating away from the deeper-adopted tool is more expensive than migrating away from the shallower-adopted one, even if the shallower one is technically "better."
Integration position. Which tool integrates with more of the rest of your stack? Tools that sit at the centre of your data flow are harder to replace than tools at the edges. Pick the tool whose connections are more valuable.
Trajectory. Which vendor is moving in the direction your business is moving? Tools that are static while you're growing become bottlenecks. Tools that are over-engineering for enterprises while you're a 35-person business become unaffordable. Check the product roadmap and the recent release notes before consolidating onto a tool.
If the tool you'd choose technically isn't the one with the team's adoption, run the math. The "right" tool that the team won't use is worse than the "wrong" tool the team is fluent in.
Step 6: Run the migration like a project, not a memo
For each consolidation, a real project. Not a Friday-afternoon decision and a Monday-morning email.
A working migration plan has:
- A named owner. One person. Not a committee.
- An inventory of what's actually in the deprecated tool (data, workflows, integrations, attachments, history).
- A mapping of each item to where it goes in the surviving tool, with a "what if it doesn't fit" answer for each.
- A pilot period where both tools run in parallel and the team learns the new one without losing the old one.
- A cutover date with a fallback plan if the cutover surfaces problems.
- A retirement date for the deprecated tool, scheduled and committed.
Most consolidations want to skip the parallel-run period because it costs money (you're paying for both tools during the overlap). Don't skip it. The overlap is what protects you from the migration discovering an undocumented dependency at the worst possible moment.
A note on building the right shape
The right tech stack for a service business isn't a single answer. It depends on the work you do, the size of the team, the integrations you need, and how mature your operations are.
But the right shape of a stack is more stable. A small number of system-of-record tools at the centre (financials, CRM, project management, document hub), surrounded by integrated point solutions, with as little duplication as possible. AI tooling layered over the top, drawing from the systems of record rather than running in parallel.
Most 30-tool stacks we audit can land at 12-18 tools after rationalisation. The savings are usually meaningful, but the bigger win is the friction reduction. The team stops losing daily minutes to "where do I log this" decisions. The data flows where it needs to. Reporting becomes possible because everything points at one source.
If this is the shape you want, the path is six steps in priority order: audit, map, prioritise, decide carefully, migrate like a project, repeat. Don't do all of it at once. The team's capacity to absorb change is the rate limit, not your willingness to make decisions.