The SaaS market has a subscription product for everything. Procurement teams love SaaS because it is fast to deploy, predictable to budget, and easy to cancel. Genuine advantages. But there is a pattern across our enterprise clients that nobody talks about at the SaaS sales dinner: the gap between what the tool does and what the business actually needs.
What You Need to Know
- SaaS is excellent for standard, well-understood workflows where the tool's model matches your needs
- The problem emerges when your process, data model, or integration requirements diverge from what the SaaS vendor assumed
- Customisation within SaaS platforms has a ceiling, and hitting that ceiling mid-project is expensive
- The total cost of ownership for heavily customised SaaS can exceed bespoke, with less flexibility
The SaaS Sweet Spot
Let me be clear: SaaS is the right answer for most software needs. If you need email, use Google Workspace or Microsoft 365. If you need accounting, use Xero. If you need a CRM and your sales process is fairly standard, Salesforce or HubSpot will serve you well.
These products are built for common workflows that thousands of organisations share. The vendor invests millions in refining those workflows. You benefit from that investment at a fraction of the cost. The economics are unarguable.
$85B
global SaaS market size in 2019, up from $58B in 2017
Source: Gartner, 2019
The growth isn't surprising. SaaS removes infrastructure burden, reduces upfront cost, and shifts risk to the vendor. For IT leaders managing budgets and headcount, it's a compelling model.
Where It Breaks Down
The trouble starts when the business process doesn't match the tool's assumptions.
Every SaaS product embeds a model of how work should flow. Salesforce assumes a particular shape of sales pipeline. Monday.com assumes a particular shape of project tracking. These assumptions are invisible when they match your reality. They become painfully visible when they don't.
We worked with an organisation last year that had spent eighteen months trying to make a well-known SaaS platform handle their approval workflow. The platform assumed linear approvals: step one, step two, step three. Their actual process had conditional branching, parallel reviews, and escalation paths that changed based on risk rating. They'd built so many workarounds that the "simple SaaS solution" required two full-time administrators to maintain.
The tool technically worked. But the organisation had bent itself to fit the software rather than the other way around.
The Customisation Ceiling
Most SaaS platforms offer customisation. Custom fields, workflow rules, integrations, even scripting environments. Salesforce has Apex. Dynamics has Power Platform. These are powerful tools.
But every platform has a ceiling. The customisation only extends as far as the vendor's data model and architecture allow. When you hit that ceiling, you're stuck. You can't refactor the platform. You can't change the underlying data model. You're limited to what the vendor decided to expose.
The worst-case scenario is discovering that ceiling six months into implementation, after significant investment in configuration and training.
The Integration Problem
SaaS products are designed to be self-contained ecosystems. They integrate with other tools, but on their terms. API limitations, rate limits, data model mismatches, and authentication complexity all add friction.
When you need to connect three SaaS products plus two internal systems, the integration tax compounds. Each connection has its own constraints. Data flows become fragile chains where a change in one system breaks another.
The pitch is always "it integrates with everything." The reality: it integrates with everything, as long as you accept their data model, their rate limits, and their definition of what a contact record looks like.
Hassan Nawaz
Senior Developer
When the Process IS the Advantage
This is the crux. For some organisations, the way they do things is their competitive edge. A logistics company with a proprietary routing algorithm. A financial services firm with a unique compliance workflow. A healthcare provider with a patient pathway that's been refined over twenty years.
Forcing those processes into a generic tool doesn't just create friction. It erodes the advantage. The organisation becomes more like every other user of that platform. The unique process gets smoothed out, simplified, and standardised until it's indistinguishable from the default.
That's fine if the process wasn't valuable. But if it was the thing that set you apart, you've traded a competitive advantage for a subscription fee.
The Total Cost Question
SaaS looks cheap on day one. Low setup cost. Predictable monthly fee. But the total cost of ownership over five years tells a different story when heavy customisation is involved.
Licence fees scale with users. Premium tiers unlock features you need. Customisation requires specialist consultants. Integration requires middleware. Training requires change management. And if you ever want to leave, migration out of a heavily customised SaaS environment is a project in itself.
We've seen cases where the five-year total cost of a heavily customised SaaS deployment exceeded what a bespoke system would have cost, while delivering less flexibility and more vendor dependency.
The Honest Assessment
Here's the decision framework we use with clients.
Use SaaS when: The workflow is standard. The data model fits. The integration requirements are straightforward. The vendor's roadmap aligns with your future needs.
Build bespoke when: The process is genuinely unique. The data model is complex or non-standard. Integration requirements are deep and bidirectional. The system needs to evolve in ways the vendor can't predict.
The grey zone: Most decisions live here. The process is mostly standard but has important exceptions. The SaaS product does 80% of what's needed but the missing 20% is critical. In the grey zone, the answer depends on whether that 20% gap can be bridged without hitting the customisation ceiling.
There's no universal right answer. But there is a wrong approach: assuming SaaS will work because it's popular, without honestly assessing the fit.