Software subscriptions have a way of accumulating quietly. One tool for project management, one for client communication, one for reporting, one that someone signed up for eighteen months ago and nobody’s entirely sure why. Each one, on its own, felt like a reasonable decision at the time. Together, they add up to a number that tends to surprise people when they actually look at it.
This isn’t an argument against software subscriptions. Most of them are genuinely useful, and the right tool at the right price is one of the better investments a growing business can make. But there’s a point at which the economics shift — where what you’re paying no longer reflects what you’re getting — and it’s worth understanding where that line is.
The per-seat problem
Most business software is priced per user, per month. In the early days of a team, this feels fine. Five seats at £20 each is £100 a month — manageable, forgettable.
The problem is that this number scales with your headcount, not your usage. As you hire, the cost goes up whether or not the new people actually need the tool, or use it in any meaningful way. By the time you have fifteen or twenty people, you’re paying for fifteen or twenty seats in every tool, even though the reality is usually that a handful of people use each one regularly and the rest log in occasionally.
The honest question to ask about any per-seat tool is: if you stripped out the people who barely use it and only paid for active users, what would the real cost be? And is the value being generated — by the people who do use it — worth that?
The workaround problem
A more telling sign that a tool isn’t working for you: you’re running a workaround alongside it.
This looks like maintaining a spreadsheet to capture the things the tool can’t handle. Or exporting data out of it every month to do something the tool should theoretically do but doesn’t quite manage. Or building a process that lives partially inside the software and partially outside it, because the software doesn’t cover the whole job.
When this happens, you’re effectively paying twice. Once for the subscription, and once in the time your team spends on the workaround. The software isn’t saving you work — it’s changed what the work looks like, without reducing how much of it there is.
This is the version of the problem that tends to build quietly. The workaround becomes normal. The team adapts to it. Nobody questions it because it works, technically. But the cost is real, and worth quantifying.
The configuration problem
Some tools are cheap and flexible enough to be shaped into what you need. Others come with a specific way of doing things, and adapting to them means changing how your business works rather than the other way around.
The configuration problem is when a tool almost fits, but getting it to fully fit would require either significant setup time, a paid implementation, or reshaping your process to match the tool’s logic. In these cases, the upfront licence cost isn’t the real cost. The real cost is what it takes to make the thing actually work for you — and often, whether anyone has done that fully or whether it’s been set up well enough to get by.
The question worth asking is: are we using this tool, or are we working around it?
A simple audit
If you want to do a quick health check on your current software costs, here’s a straightforward approach.
List every subscription you’re paying for. For each one, write down:
- The monthly cost (total, not per seat)
- How many people use it regularly — not occasionally, regularly
- What it would cost in time or money to operate without it
The third question is the important one. If the answer is “it would take an hour a week of manual work to replace”, that’s useful information. If the answer is “we genuinely couldn’t function without it”, that’s useful information too. The tools worth paying for are the ones where the alternative is significantly worse. The ones worth questioning are the ones where the alternative is a bit of spreadsheet work that a small team could manage.
This exercise often surfaces one or two tools that nobody would miss if they disappeared, and one or two that are clearly earning their cost. The ones in the middle are the ones worth thinking about.
When building something makes more sense
There’s a category of problem where neither paying for a subscription nor doing things manually is the right answer — where the better option is building something you own outright. The build vs. buy decision is worth thinking through properly rather than defaulting to whichever option is most familiar.
This tends to be the case when:
- The tool you need doesn’t exist, or the closest thing on the market requires so many compromises that it never quite works
- Your use case is specific enough that you’d spend more time configuring a generic tool than it would take to build something tailored
- The per-seat cost is becoming significant as your team grows, and the tool is doing a defined, bounded job that a custom solution could do instead
- You’ve been on a trial for something and decided not to pull the trigger — because the fit wasn’t right, the price wasn’t right, or both
The upside of building is that you own what you’ve built. There’s no renewal conversation. No per-seat pricing that follows your headcount. No dependency on a vendor keeping a feature or a pricing model you’ve structured your operations around.
The obvious limitation is that building takes time and expertise — and not every problem is worth the investment of either. The right call depends on how central the task is, how often it runs, and what it costs you currently to do it the way you’re doing it.
The honest answer
There’s no universal threshold. A £200-a-month subscription is excellent value if the alternative would cost you three hours of a director’s time every week. It’s poor value if it’s handling one task that a simpler, cheaper, owned solution could do just as well.
The discipline is doing the comparison honestly rather than letting subscriptions accumulate by default. Most businesses, when they do that audit, find at least one tool they’d cancel and one situation they hadn’t considered building a solution for.