The 20% Problem: Why You're Paying Full SaaS Price for Features You'll Never Use

A CTO opens their annual SaaS expense report. HubSpot: £12k per year. BambooHR: £6k. Workday: £15k. Then the rest: Jira, Confluence, Slack premium, DocuSign, three analytics tools, two project management platforms. Total SaaS spend creeps past six figures. The spreadsheet is long. The question nobody asks is short: how much of this do we actually use?

The honest answer, for most organisations, is somewhere between 10% and 20%. Not because the tools are bad. Because SaaS products are built for everyone, and your team is not everyone.

How did we get here?

The pattern is familiar because nearly every organisation has lived it.

You buy a SaaS tool to solve one specific problem. Maybe it is CRM, maybe it is HR onboarding, maybe it is project tracking. The tool works well for that narrow use case. Then the vendor’s sales team calls. They have an adjacent feature set, a new module, an enterprise tier that bundles everything together. Your per-seat cost looks better on the higher plan. You upgrade.

Within a few weeks of adoption, your team settles into a fixed set of workflows. They use the same five or six screens. They build the same three reports. The other 80% of the platform sits untouched. It is not that the features are bad. It is that your team bought the tool to do one thing, and that one thing is what they do.

This is not a failure of the SaaS product. It is a structural mismatch between how SaaS is sold and how it is used. The vendor’s incentive is to bundle, because more features justify higher pricing. The buyer’s reality is that most teams need a fraction of what they are paying for.

What does 20% utilisation actually cost?

The subscription is the visible cost. It is not the total cost.

When you adopt a SaaS platform that does more than you need, you inherit a set of hidden expenses that rarely appear on any invoice. Integration middleware sits between the SaaS tool and your actual systems. Someone built those connectors. Someone maintains them. When the SaaS vendor ships an API change, someone fixes the integration at short notice.

Training costs accumulate for features nobody uses. Onboarding documentation covers the full platform, not your five screens. New hires spend time learning capabilities they will never touch. The overhead is small per person but compounds across teams and years.

Workarounds emerge for workflows that almost fit but not quite. Your process needs an approval step that the SaaS tool does not support. So someone builds a spreadsheet alongside it, or a Slack channel becomes an unofficial approval workflow. The SaaS tool handles 80% of the process. The remaining 20% lives in duct tape.

Compliance gaps appear when the SaaS tool cannot be configured to meet your specific regulatory or governance requirements. You end up layering manual checks on top of automated workflows, which defeats the purpose of the automation.

The true cost of a SaaS tool is the subscription plus the delta between what it does and what you need. That delta is where the 20% problem lives.

Why was custom software not the answer before?

The obvious response to the 20% problem has always been: build your own. For most of the last two decades, that response was impractical.

Traditional custom development was slow. A focused build targeting a single business workflow took six to eighteen months from specification to production. Requirements changed during that window. The thing you delivered at the end was often out of step with what the business needed by the time it arrived.

It was expensive. Even a modest custom build started at £150k or more, once you factored in discovery, architecture, development, testing, and deployment. For a tool that replaced a £12k per year SaaS subscription, the payback period stretched to over a decade.

It was risky. Custom projects carried a meaningful probability of failure, particularly when scope expanded mid-build. The SaaS tool, for all its waste, at least worked on day one.

The economics simply did not support building a narrow, purpose-built tool to replace a general-purpose SaaS platform. You needed to be replacing something very expensive or building something genuinely unique to justify the investment. For the 20% problem specifically, the maths did not work.

What changed?

AI-augmented development has compressed custom build timelines by 40-50%. This is not a theoretical projection. It is the trajectory we see across engagements, measured quarter by quarter in our AI Velocity Report and documented in our approach to shipping AI in the real world.

A focused custom build targeting your actual workflows (not a full platform rebuild) now takes 8-16 weeks. Tools like Claude Code, Cursor, and GitHub Copilot accelerate the parts of development that used to consume the most time: scaffolding, front-end patterns, integration code, and test generation. The expensive parts, discovery, architecture, and quality assurance, remain human-led. But the total cost per feature has dropped enough to change the equation.

Building the 20% you actually use is now cheaper than buying the 100% you do not. The break-even point has shifted from years to months.

This does not mean every SaaS subscription should be replaced with custom software. It means the category of use cases where custom software is viable has expanded significantly. Problems that were too small to justify a custom build two years ago are now within reach.

For a detailed breakdown of how this affects project budgets, see what AI-augmented development means for your budget.

When is the 20% problem worth solving?

Not every SaaS tool with low utilisation is a candidate for replacement. The decision depends on several factors, and being honest about them is more useful than a blanket recommendation.

Solve it when:

• You can identify the specific workflows your team uses daily, and they represent a small, well-defined subset of the platform
• The SaaS integration layer is a chronic pain point, consuming ongoing engineering time to maintain connectors and workarounds
• Compliance or governance requirements force manual workarounds because the SaaS tool cannot be configured to meet them
• You are paying for a premium tier to access a single feature that could be built independently
• The vendor’s roadmap is diverging from your needs, and you are funding development of features for other customers

Leave it alone when:

• You genuinely use most of the platform’s capabilities (70%+ utilisation is a strong signal to stay)
• The SaaS vendor’s domain expertise exceeds what you could realistically build, for example, payroll tax calculation or global compliance databases
• Switching costs are prohibitively high, either in data migration complexity or organisational change management
• The tool is genuinely commodity infrastructure: email, chat, basic file storage, video conferencing

The guide to when to replace SaaS with custom software provides a structured decision framework for working through this assessment. If you are considering a replacement that involves replicating existing functionality, the UK legal guide to SaaS replacement covers what you can and cannot copy, and how to structure the project defensibly.

The calculation your CFO will ask about

The CFO’s question is simple: does the custom build cost less than the SaaS subscription over a reasonable time horizon?

The inputs are straightforward. Take your current SaaS spend for the tool in question. Add the annual cost of integration maintenance, workarounds, and compliance overhead. That is your true annual cost. Multiply by five years.

Compare that against the cost of a focused custom build (typically £25k-£80k for a narrowly scoped SaaS replacement) plus annual support and hosting costs. For most of the cases where the 20% problem applies, the custom build breaks even within 18-30 months and saves money every year after.

The numbers only work when the utilisation gap is genuinely large. If you are using 60% of a SaaS platform, the subscription is almost certainly better value. The 20% problem is specifically about the cases where you are paying for a platform and using a feature.

For a broader view of how this fits into your technology strategy, our guide to replacing SaaS with custom AI-built software covers the full decision framework, from assessment through delivery.

What this is not

This is not an argument against SaaS. SaaS is the right model for most software, most of the time. It is the right choice when you need broad functionality, when the vendor’s domain expertise is genuinely valuable, and when you want someone else to handle infrastructure and updates.

This is an argument against paying for software you do not use, when a viable alternative now exists. The 20% problem was always real. What changed is that solving it became affordable.

If you are looking at specific SaaS tools in your stack, we have written about replacing HubSpot with a custom AI-built CRM as a worked example. The questions around who owns AI-written code are also worth reading before starting any replacement project.

Start with the expense report

If your SaaS expense report feels like it should be smaller, it probably should be. The first step is a simple audit: for each tool, how many features does your team use weekly versus how many you are paying for?

We offer a free 30-minute SaaS Replacement Assessment where we review your current SaaS stack, identify the tools where the 20% problem is costing you the most, and outline whether a custom build makes financial sense.

Book a consultation and bring the expense report.