What you'll take away
The average mid-market company is paying for 130 SaaS applications (Productiv, 2024 SaaS Trends Report). Of those, 44% are underutilised — defined as fewer than 10% of licensed seats actively used in the previous 30 days. The average SaaS application stack has 22% functional overlap with at least one other tool in the portfolio. And the integration layer connecting those tools — custom scripts, middleware platforms, and the manual work required to keep data consistent across systems — adds a cost that does not appear on any individual software invoice.
None of this appears on the CFO's dashboard as 'software inefficiency.' It shows up as IT headcount, consulting spend, and the engineering sprint capacity consumed by integration maintenance that should be building product.
The SaaS model was supposed to remove the capital cost of enterprise software. It has replaced it with an operational cost that is less visible, harder to govern, and — at sufficient scale — more expensive.
The Four Costs Nobody Tracks
1. Licence Waste
The most visible SaaS cost — and the one most commonly audited — is licence waste: seats purchased that are not actively used. Productiv's 2024 research found that the average enterprise wastes 28% of its SaaS spend on unused or underutilised licences. For a company spending £500K annually on SaaS, that is £140K in direct licence waste before any other cost category is considered.
2. Integration Cost
The integration cost of a SaaS portfolio is invisible because it is paid in engineering time, not on a software invoice. Each point-to-point integration between two tools requires build time, test time, and ongoing maintenance as both tools evolve. A 15-tool SaaS stack with full integration connectivity requires up to 105 point-to-point integrations — and in practice, integration complexity is one of the most common reasons engineering teams fall behind on product roadmap commitments.
3. Data Fragmentation Cost
When the same entity — a customer, a contact, an order, a contract — is represented in multiple tools with no reliable synchronisation, every business process that spans those tools requires data reconciliation work. Sales reps reconcile CRM and support data before customer calls. Finance reconciles billing system and CRM data for revenue reporting. Operations reconcile project management and time-tracking data for capacity planning. The cumulative cost of this reconciliation work — in hours, in errors, in delayed decisions — is typically underestimated by a factor of three.
4. Vendor Management Cost
Managing 130 SaaS relationships means 130 annual renewal cycles, 130 security review requirements, 130 data processing agreements to maintain, and 130 contractual relationships to govern. At enterprise scale, SaaS vendor management requires dedicated procurement and legal resources — resources that could be significantly reduced by consolidating the vendor portfolio.
Gartner analysis found that enterprises with more than 100 SaaS applications spend an average of 32% of their total SaaS budget on integration, maintenance, and data reconciliation — costs distributed across IT, engineering, and operations budgets and therefore rarely attributed to the SaaS stack itself.
When SaaS Is the Right Answer
SaaS is not the wrong answer. It is the right answer for commodity workflows — functions that are not part of your competitive differentiation and where the problem is well-understood, the solution is mature, and the configuration options are sufficient for your needs.
- Finance and accounting: general ledger, accounts payable, expense management — commodity functions where building custom software provides no competitive advantage
- HR and payroll: well-defined compliance requirements, mature SaaS solutions, no proprietary IP at stake
- Email and communication: infrastructure that should not be differentiated
- Standard CRM for simple sales processes: where Salesforce or HubSpot's standard functionality covers the use case without requiring significant customisation
When Building Wins
Building custom software is the right answer when the workflow being automated is a source of competitive differentiation — when the way your company executes a process is better than the competition, and maintaining that advantage requires owning the software that executes it. It is also the right answer when compliance requirements constrain what a SaaS solution can do, when the integration complexity of connecting a SaaS tool to your existing stack exceeds the cost of building a native capability, or when the SaaS licensing cost at your scale exceeds the amortised build and maintenance cost of a custom solution.
Legacy code is a tax you pay every sprint
48-hour turnaround. No obligation.
The Four Build-vs-Buy Questions
- 1Is this process part of our competitive differentiation? If yes, buying the same tool as your competitors provides no advantage — and may prevent you from innovating in the process.
- 2What is the five-year total cost of the SaaS option, including integration, training, and scaling costs? SaaS sticker prices understate total cost by 40–60% on average when integration and scaling are included.
- 3Do our compliance requirements constrain what a SaaS solution can do? Regulated industries frequently find that SaaS data residency, retention, and audit logging requirements preclude the most capable solutions.
- 4What is the integration complexity cost? If connecting the SaaS tool to your existing systems requires six months of engineering work and ongoing maintenance, factor that into the comparison — it is part of the cost of the SaaS decision.
The Hybrid Architecture: Custom Core, SaaS Periphery
The most effective enterprise software architectures are not 'all SaaS' or 'all custom' — they are hybrid: a custom core for the processes that define competitive advantage, surrounded by best-in-class SaaS for commodity functions, connected by a well-designed integration layer.
The custom core might be a proprietary workflow engine, a specialised data model, or a customer-facing application that directly delivers the product or service. The SaaS periphery handles the undifferentiated support functions — finance, HR, communication, standard CRM. The integration layer — whether built on a modern iPaaS platform or as custom API infrastructure — connects the two without creating the point-to-point integration complexity that characterises unmanaged SaaS sprawl.
The Economics of Going Custom
The common objection to custom software is cost: building software is expensive, and SaaS is cheaper. This is often true at the point of initial deployment. It is frequently false over a five-year horizon at scale.
A mid-market company paying £80K/year for a specialised SaaS tool that covers 60% of its needs — requiring £30K/year in integration maintenance and £20K/year in manual workarounds for the remaining 40% it does not cover — is paying £130K/year for a solution that would cost £200K to build once and £20K/year to maintain. The payback horizon is 2.3 years. At year five, the company running custom software has spent £300K total. The company running SaaS has spent £650K.
The Audit That Changes the Conversation
Most organisations that discover they are paying more for SaaS than a custom alternative would cost do so through a total cost of ownership audit that surfaces the hidden costs for the first time. The audit typically reveals three categories of waste: redundant tools serving the same function, integrations consuming engineering capacity that could be eliminated by consolidation, and manual reconciliation processes that are a direct consequence of data fragmentation across too many systems.
The audit output is not always 'build everything custom.' It is frequently 'consolidate from 130 tools to 60, integrate properly, and identify the three workflows where a custom solution would outperform any available SaaS option.' That is a different conversation — and a more useful one — than the one most software procurement processes generate.
GYSP's Custom Software Development practice begins every engagement with an honest build-vs-buy analysis and recommends building only when the five-year economics justify it. We have recommended SaaS consolidation as frequently as we have recommended custom development — because the right answer depends on the specific workflow, the specific compliance context, and the specific scale.
“The decision to buy SaaS or build custom is not a technology decision — it is a strategic one. Companies that treat it as a technology procurement question miss the competitive and economic implications of owning versus renting the software that runs their core business.”
— Dhaval Rana, Founder & CEO — GYSP.tech
