Too Many Tools: How to Decide What to Cut

The short answer

Do not decide by counting tools. Decide by asking who would actually be stuck if a service disappeared tomorrow. Anything the whole team touches daily stays. The place to start looking is the service a few people open a couple of times a month.

If cutting the number becomes the goal in itself, you will switch off something the floor was quietly relying on, and the work returns as manual effort. Before cutting anything, write down what is stored where.

What actually became the burden

When a stack of services starts to feel heavy, it is usually one of these. Tick the ones you recognise.

• Account admin. Every hire and every leaver means adding or removing an account once per service. Missed removals show up as a former employee's account still sitting there.
• The same data kept twice. A customer contact name lives in both the quoting service and the contact list, and one of them stays out of date for months.
• Scattered notifications. Requests arrive by email, by chat, and as comments inside a service. Nobody can say which place shows all of them.
• Stacked monthly fees. Each one is small; the annual total is not, and it usually includes seats nobody uses.
• Training cost. Every new hire needs a longer walkthrough, which eats the time of whoever gives it.
• Losing track of data. After a contract ends, somebody asks where that document went.

One or two ticks is not a problem. At three or more, move on to the decision below.

The criteria for cutting

Go service by service and answer four questions. Hesitating on an answer is itself information — that service has not taken root.

1. Is there an alternative? Can something you already pay for do the same job? If it can, but with obviously more steps, do not merge.
2. What survives if you stop? Can you export the data, and will the exported format still be readable later? Anything that only exports into a format you cannot open needs handling before you cancel.
3. Who uses it daily? Can you name them? If you cannot name anyone, it may not be in real use.
4. Does work stop if the service goes down? If it does, this is not something to swap out casually.

Question two is worth answering right now, whether or not you cut anything.

What to merge, and what to keep apart

Collapsing everything into one platform is not automatically better.

Merge things that hold duplicate information — customer contacts, schedules, internal announcements. When these are split, every update becomes several updates, and one of them gets missed.

Keep apart things with different audiences. Payroll and personnel records do not belong in the same place as announcements everyone reads. If you put two different audiences in one system, you will spend your time maintaining fine-grained permissions forever.

When you are unsure, ask one question: if I merge these, does the number of people who can see this grow? If yes, leave them separate.

What this looks like in practice

Take a food processing business with six staff. Orders arrive by email, stock is tracked in Excel, site photos are shared in chat, and invoices are produced in yet another service.

The first thing to fix is not the stock spreadsheet. Start by counting how many places hold customer contact details. If the answer is three, name one of them the source of truth and make the other two point at it. Next, pull incoming requests into one channel. Even a plain rule — anything that arrives by email gets posted into chat — makes a difference.

Leave the photo sharing alone. The site crew uses it every day and there is no replacement.

Cloud and local, deliberately split

APOUL LCC (Life Connect Cloud) is the idea of not leaning entirely on either side. Anything that needs sharing, syncing or simultaneous editing belongs in the cloud. Anything that finishes inside one device can stay on that device.

That line helps when you are trimming services. Pasting boilerplate text, drafting a document, adding up figures for your own use — none of this needs to be shared with anyone, and putting it in an external service adds an account, a notification stream and a monthly fee without adding value. The reverse mistake is just as common: keep a file several people need on individual machines and nobody can say which copy is current.

In short

The number of tools is not the target. The burden is one of six things: accounts, duplicate data, scattered notifications, cost, training, or lost data. For each service, check whether an alternative exists, what survives if you stop, who uses it daily, and what breaks if it goes down. Merge duplicated information; keep different audiences apart. Decide the cloud-and-local line too, and the next "should we add this?" question gets much quicker to answer.