Nine Apps, Three Jobs: Untangling Your Team's Tool Sprawl Before It Eats the Budget

There's a particular spreadsheet that every ops lead eventually builds. It has every subscription on it, colour-coded by whether anyone can still remember the login, and it usually appears the week finance asks a very simple question: what exactly are we paying for?

In 2026, that answer is rarely simple. A team of forty people might be running Slack for chat, Teams because one client insisted, Notion for docs, a leftover Confluence instance, Miro for workshops, FigJam because a designer prefers it, Loom for updates, a scheduling tool, a project tracker, and at least two things nobody has opened since the spring. Every single one was a reasonable decision at the time. Stacked together, they're a maze.

The encouraging bit is that you don't need a consultant or a six-month transformation programme. You need a fortnight, one shared spreadsheet, and the willingness to mildly annoy about four people.

Start with the receipts, not the vibes

Ask people which tools they use and you'll get a list of favourites. Ask the bank feed and you'll get the truth.

Pull three months of card transactions and direct debits, filter for anything ending in .io, .com or .app, and match them against invoices. Include the annual renewals hiding in a finance folder, the seats bought on someone's personal card and expensed, and the free tiers that quietly became paid when the workspace crossed a user limit. VAT receipts matter here too — if you're reclaiming, you want the paperwork straight before HMRC season gets busy.

The output is a single list: tool, owner, monthly cost, seat count, renewal date. If a line has no owner, that's your first finding.

Map overlaps against jobs, not departments

Forget org charts. List the jobs your team actually does — talk quickly, write things down, decide, plan the next six weeks, run a workshop, share a file, book time. There are usually six or seven, not sixty.

Then draw a grid: jobs down the side, tools across the top, ticks where a tool genuinely does the job. What you're looking for is the clumps. Three tools doing 'write things down'. Two doing 'book time'. A project tracker and a doc tool both pretending to be the place where decisions live — which is the classic one, and it's why nobody can find the decision from March.

Be honest about the difference between overlap and duplication. Two tools doing the same job with the same people is duplication. Two tools doing adjacent jobs is often fine.

Put a number on the waste

SaaS pricing is designed to feel small. Per seat, per month, plus VAT, and somehow it's never the amount anyone remembers.

Work it out properly. Seat-based collaboration tools commonly land somewhere between £6 and £16 per user per month, so for a forty-person team every redundant tool is roughly £3,000 to £7,500 a year — before the annual plan discount you were talked into. Find two genuine duplicates and you've paid for a decent team away-day, or a chunk of the hiring budget you've been arguing about since the last budget round.

There's a subtler cost too: the sprawl itself. Every extra tool is another place to check, another notification setting to tame, another password reset on a Monday morning.

Count the time tax

The time cost is harder to put on a slide but it's the bigger number. It shows up as the five minutes hunting for the right board, the duplicated note, the meeting that exists purely because two people couldn't see each other's updates.

Try a one-week diary note: every time someone switches tool to find something, they jot it down. Ten entries per person per day at ninety seconds a go is a quarter of an hour — per person, per day. Nobody will do this perfectly, and that's fine. The pattern is the point.

Apply the one-job rule

Here's the consolidation principle that survives contact with real teams: each core job gets one home, and there's one place where the team actually meets.

That second part is where a lot of stacks fall over. You can rationalise docs and tasks beautifully and still have five places where a conversation happens. Kula works as that connective layer — spaces for the team, async updates that land in one feed, docs that sit next to the discussion rather than in a separate tab, and short circles instead of another recurring call. The aim isn't to be the tenth tool on the list; it's to make three of the others unnecessary.

A realistic post-audit stack for a forty-person UK company often looks like: one chat tool, one doc-and-decision space (Kula), one project tracker for the genuinely delivery-heavy teams, one design tool, one scheduler. Five things, clear jobs, one owner each.

The bit where people get grumpy

Nobody enjoys being told their favourite tool is going. Expect the designer who has built a whole system in one board, the PM with a tracker full of history, and the person who genuinely needs the accessibility features of the thing you're culling.

Three rules help. Don't remove anything mid-project — set a switch-off date at a natural boundary. Migrate the useful content, archive the rest, and say publicly where the archive lives so nobody panics. And let the loudest objector own the migration for their area; people defend what they're responsible for, and often do it rather well.

A thirty-day plan

• Days 1–3: pull the receipts, build the list, assign an owner to every line.
• Days 4–7: map tools to jobs, mark the clumps, flag the duplicates.
• Days 8–10: price the waste, count the time, write a one-page summary nobody needs a meeting to read.
• Days 11–14: decide the target stack and the switch-off dates. Circulate in writing.
• Days 15–28: migrate the things worth keeping, archive the rest, run the first week with the new setup and a named person on hand for questions.
• Day 30: review. Cancel anything still unused, and book the next audit for six months' time.

The point isn't minimalism for its own sake. It's that a team with fewer, clearer places to work spends less time working out where to work — and in a year when every line of spend gets a second look, that's a decent place to start.