The tool that almost fits
You trialled five SaaS tools. One covered about 80% of what you needed, had decent reviews, and the pricing looked manageable. So you bought it.
Twelve months later, your team has a spreadsheet running alongside it. The spreadsheet handles what the tool can't. The tool handles what the spreadsheet can't. Neither knows about the other. Every week, someone reconciles them.
That's not a workflow problem. That's a fit problem. This post is about how to tell the difference — and what to do once you have.
When off-the-shelf is the right answer
Most businesses should start with SaaS. It's fast, cheap to get going, and someone else handles the infrastructure. If your process is broadly standard — bookkeeping, HR, email marketing — there's probably a tool built for it, and adapting slightly to fit the tool costs less than building from scratch.
Off-the-shelf also wins when you haven't yet stabilised the process. If you're still working out how a workflow should run, building custom software locks in your current best guess before you've had time to learn. A SaaS tool is a cheaper placeholder. Start there.
The right time to reconsider isn't when the tool isn't perfect. No tool is. The right time is when the tool's imperfections have started costing you something real.
When the maths changes
Per-seat pricing feels manageable until the team grows.
£15 per person per month for a 10-person team is £1,800 a year. Fine. The same tool for 50 people is £9,000 a year — and that's before the vendor's next price increase, which will come. SaaS pricing climbs year on year as platforms mature. The rate on a legacy plan today is not the rate you'll be paying in three years.
That number looks different next to a custom build. Software built once for £8,000–£15,000, maintained for a few hundred pounds a month, pays for itself somewhere between two and three years — and then stops costing you per head regardless of how many people you hire.
The cost comparison alone isn't the argument. But when it crosses the threshold and your team is also fighting the tool daily, the two together make a real case.
When the fit breaks
Price is one signal. The sharper one is when your team stops trusting the tool to handle the job it was bought for.
The signs are usually small before they're large. A field that almost maps to your data structure but not quite. A report you export every week and rework in Excel because the built-in one doesn't show what you need. An approval step your process requires that the tool doesn't support, so someone sends an email alongside it to cover it off.
Workarounds accumulate. Six months in, the spreadsheet that started as a stopgap is now load-bearing. The SaaS tool handles the bits of the process it was designed for, and the bits it can't handle have quietly been handed back to your team.
Integrations are where this often surfaces most clearly. If you're running three or four tools that don't connect to each other, someone in your business is copying data between them every day. That's a job a proper integration does automatically. The per-seat cost of each tool is only part of what you're paying — the manual transfer work is the hidden cost sitting underneath.
The question to ask yourself
Before commissioning anything, ask two things in order.
First: is the process stable? If you're still working out how the workflow should run, custom software will lock in the wrong answer. Wait until it has settled.
Second: are you paying for the problem twice? Once in licensing, and again in the hours your team spends working around what the tool can't do. If both are true, the conversation about a custom build is worth having.
If only one is true — the tool is expensive but works fine, or it's imperfect but cheap and the workarounds are minor — you're probably not at the threshold yet.
Where we land
Off-the-shelf is the right default. It gets a business moving quickly and the good tools in any vertical are genuinely good.
Custom software makes sense when two things are true at the same time: the per-seat cost has grown to where a build pays for itself within two or three years, and your team is working around a tool that wasn't designed for how you actually operate.
Neither alone is enough. Both together usually is.
If you're staring at a spreadsheet your team built to compensate for what the SaaS tool can't do, it's worth a conversation.