Most growing UK businesses run on a patchwork of SaaS tools: a CRM, an accounting package, a helpdesk, maybe an inventory system, all stitched together with spreadsheets and a fair amount of manual re-entry. That's not a failure of planning. It's the sensible starting point. SaaS is cheap to start, fast to deploy, and someone else carries the maintenance burden. The question isn't whether SaaS is good. It's whether it's still the right fit as the business changes shape.
This is a decision worth making deliberately, not by default or by inertia. Below is a practical framework for weighing the two options across the dimensions that actually matter commercially: cost over time, ownership, integration, scalability, security, and who's on the hook when something breaks.
Cost: sticker price vs total cost of ownership
SaaS pricing is designed to look small. A monthly per-seat fee is easy to approve without much scrutiny. But the real cost curve tends to bend upward as a business grows: more seats, higher usage tiers, paywalled features you only discover you need once you're already dependent on the platform, and add-on modules that quietly become essential. Looked at over three to five years rather than month one, the total spend is often substantially higher than it first appeared, and it scales with headcount rather than with value delivered.
Custom software inverts this. The upfront cost is real and has to be budgeted honestly, there's no getting around that. But once built, the ongoing cost is largely maintenance and hosting, not a recurring per-user tax. For a business that expects to keep growing its headcount or transaction volume, this changes the shape of the cost curve considerably. The right comparison isn't build cost vs one year of subscriptions. It's build cost plus five years of maintenance vs five years of subscription growth, including the tiers and add-ons you'll likely need.
The point where SaaS starts to strain
There's a fairly recognisable pattern in businesses that start questioning their SaaS stack. It usually isn't one big failure, it's an accumulation of small workarounds:
- A spreadsheet has quietly become the source of truth for something the SaaS tool was supposed to handle
- Staff manually copy data between two systems because there's no clean integration, or the integration exists but costs extra
- The business is paying for an enterprise-tier subscription just to unlock one feature it actually needs
- A process that's core to how the business competes has to be bent to fit a generic workflow rather than the other way round
- Reporting requires exporting data and rebuilding it elsewhere because the platform's native reporting doesn't match how the business actually operates
None of these alone is a reason to commission custom software. Together, and persisting over time, they're a reasonably reliable signal that the business has outgrown a tool that was never built for it specifically. The workaround itself has a cost too: staff time, error rate, and the opportunity cost of people doing manual reconciliation instead of something else.
Integration and who really owns the data
As a business connects more systems, CRM to finance to operations to a customer-facing portal, integration becomes a bigger factor than either cost or features. SaaS platforms vary enormously in how open they are. Some offer generous APIs. Others treat API access as a paid tier, or export data in formats that make migration painful, or simply don't expose the data a business needs to connect its own systems properly. This is worth investigating concretely for any platform under consideration, rather than assuming openness.
Data ownership is a genuine business risk, not just a technical footnote. If a core dataset, customer records, transaction history, operational data, lives inside a SaaS platform on that vendor's terms, the business's ability to migrate, integrate, or even fully understand its own data can be constrained by someone else's commercial roadmap. That's a reasonable trade when the data in question isn't strategically important. It's a bigger consideration when that data is central to how the business operates or competes.
Lock-in cuts both ways
It's tempting to frame this as SaaS lock-in versus custom freedom, but that's not quite honest. Both paths create dependency, just different kinds.
- SaaS lock-in: price rises, feature deprecation, forced upgrades, or a vendor being acquired or shut down, all outside the business's control
- Custom software lock-in: the business now owns a maintenance liability. Someone has to patch it, extend it, and understand it as staff and technology stacks change
The custom software risk is often underestimated because it's less visible than a subscription invoice. A bespoke system with no maintenance budget, no documentation, and no plan for what happens when the original developer moves on is a liability, not an asset. Anyone commissioning custom software needs to budget for its ongoing life, not just its build.
Security, compliance and accountability
For UK businesses, data protection obligations under UK GDPR apply regardless of whether data sits in a SaaS platform or a custom system. The difference is practical, not legal: with SaaS, a reputable vendor typically handles a chunk of the technical security work (patching, infrastructure hardening, access controls) as part of the service, though the business remains responsible for how it uses the data and who it shares it with. With custom software, that responsibility sits more visibly with the business and whoever maintains the system on its behalf.
Specific regulatory obligations, data residency requirements, and sector rules vary by industry and should be confirmed with a qualified adviser rather than inferred from general guidance like this. The point here is about where operational responsibility sits, not a substitute for legal advice.
Where SaaS is the right call
SaaS remains the sensible default for a wide range of business needs, and there's no competitive advantage in reinventing commodity functions:
- Functions that are genuinely generic across businesses: email, accounting, HR admin, basic CRM
- Early-stage or fast-changing processes where flexibility matters more than fit
- Situations where speed to deployment matters more than long-term cost curve
- Anything where the business doesn't have (and doesn't want) the internal capability to manage a bespoke system's upkeep
If a workaround costs a few hours a month and nobody's particularly bothered by it, that's not a business case for custom development. It's a rounding error.
Where custom software earns its cost
Custom software tends to be justified when the process in question is close to what actually differentiates the business, not just supports it. A few recognisable scenarios:
- A core operational workflow is genuinely unusual, and forcing it into a generic tool means constant compromise or manual patching
- The business is paying for multiple SaaS subscriptions and integration middleware that, combined, cost more than a tailored system would over a few years
- A customer-facing portal needs to reflect specific business logic or branding that generic tools can't replicate without heavy customisation fees
- Data from several disconnected systems needs to be unified into one operational view, and no off-the-shelf product does that well for this specific combination of systems
- The manual workaround (spreadsheets, copy-paste between tools, ad hoc reporting) has become a real source of error or delay that affects customers or revenue
In each of these, the case for custom software isn't about wanting something bespoke for its own sake. It's about the accumulated cost, risk, and inflexibility of forcing a growing, specific business into a generic tool exceeding the cost of building something that fits.
Making the decision
A useful way to test the decision is to look honestly at how much friction currently exists, not how much friction might theoretically exist someday. Count the workarounds. Cost the staff time they consume. Add up what the business actually pays across its current SaaS stack, including the tiers and add-ons, and project that forward three to five years against realistic growth. Then ask whether the process in question is something the business needs to do the same way as every competitor, or whether doing it differently is part of how the business wins.
If the answer is that everything's roughly fine and the workarounds are minor irritations, SaaS is still doing its job. If the answer is that the business is spending real money and real time compensating for a tool that was never built for it, that's the point where a proper scoping conversation about custom software is worth having, not before.