Your CPQ platform costs £100k a year. Your billing system costs another £100k. Your CLM tool runs £50k. Your forecasting overlay is £60k.

That's over £300k annually. Before implementation fees. Before the admin headcount to maintain it. Before the consultants you'll hire when the configuration breaks.

And most of it can now be replaced by custom AI-built systems at a fraction of the cost.

That's not a prediction. I've built them. They're running in production. And the companies using them aren't going back.

The Pricing Model That's Dying

The enterprise SaaS pricing model was built on a simple premise: the cost of building custom software was so high that it was always cheaper to buy off the shelf.

For twenty years, that held true.

Building a CPQ system from scratch meant months of engineering time, dedicated infrastructure, and ongoing maintenance that most revenue teams couldn't justify. So you signed the contract. You paid the per-seat fee. You hired the implementation partner.

That economic equation has fundamentally shifted.

AI has collapsed the cost of building business-logic-specific systems by an order of magnitude. What used to take a team of engineers six months can now be architected, built, and deployed in weeks. Not as a prototype. As a production system handling real revenue workflows.

The SaaS vendors know this. That's why they're racing to slap "AI-powered" labels on existing products. But bolting a language model onto a legacy platform is not the same thing as rethinking the architecture from scratch.

What £100k Actually Buys You

Let's be honest about what a six-figure SaaS contract delivers in practice.

You're not paying for the software. You're paying for the vendor's generic data model, their workflow assumptions, their integration ecosystem, and their customer success team who will help you configure their product to approximately fit your business.

Approximately is the key word.

Every vendor makes architectural assumptions about how businesses work. Those assumptions are baked into the product. When your business doesn't match those assumptions — and it never fully does — you have three options:

  • Bend your process to fit the tool — the most common outcome, and the most damaging. Your operating model is now shaped by a vendor's product decisions, not your commercial reality.
  • Pay for heavy customisation — configuration projects that cost tens of thousands, take months, and create technical debt that makes future changes even harder.
  • Build workarounds — spreadsheets, manual processes, and shadow systems that exist because the platform can't do what you actually need. The "Frankenstein stack" in miniature.

I've seen all three. Usually at the same company. Usually for the same tool.

The Platforms Most at Risk

Not every SaaS category is equally vulnerable. Your CRM is probably safe — the ecosystem value of Salesforce or HubSpot makes replacement impractical for most companies.

But the layer on top of the CRM? That's where the disruption is happening.

CPQ (Configure, Price, Quote)

Salesforce CPQ. DealHub. Subskribe. Conga.

These platforms charge six figures to solve a problem that is fundamentally about your specific pricing logic and approval workflows. Every implementation is heavily customised because every company's commercial model is different.

That's exactly the pattern AI-built systems excel at replacing. When the customisation is the product, the generic platform is overhead.

I've architected CPQ replacements that handle multi-currency pricing, tiered discount approvals, usage-based billing triggers, and deal desk workflows — built around the company's actual commercial rules, not a vendor's approximation of them.

Billing and Revenue Recognition

Maxio. Chargebee. Sage Intacct modules.

SaaS billing platforms are designed for the average case. But the average case doesn't exist. Every growing company has contract structures, billing schedules, and revenue recognition rules that strain the out-of-box model.

The result: months of configuration, custom fields everywhere, and a finance team that still reconciles in spreadsheets because the platform doesn't quite handle their edge cases.

Custom-built billing systems eliminate that gap. They're designed around your actual contract structures from day one. No configuration debt. No vendor constraints on how you recognise revenue.

Contract Lifecycle Management

Juro. Ironclad. DocuSign CLM. PandaDoc.

Most companies buying CLM platforms are solving a contract generation and storage problem. They're paying enterprise prices for what amounts to a template engine with an approval workflow.

That is not a £50k problem.

Custom contract systems can generate documents from structured data, enforce clause governance, manage approval chains, and track renewal timelines — all built around your legal team's actual requirements, not a vendor's demo scenario.

Revenue Forecasting

Clari. BoostUp. Aviso.

Here's the uncomfortable truth about forecasting overlays: they don't fix bad data. They make bad data look more sophisticated.

If your pipeline stage definitions are inconsistent, your forecast is wrong — regardless of how many AI models you layer on top. If your reps aren't updating opportunities accurately, no amount of signal detection will produce a reliable commit number.

Forecasting is a governance problem, not a software problem. And custom-built forecasting that's wired directly into your CRM data model — using your stage definitions, your historical patterns, your conversion assumptions — will always outperform a generic platform trained on other companies' data.

What "Custom-Built" Actually Means

Let me be specific, because "custom-built" triggers a lot of assumptions.

I'm not talking about hiring a team of engineers to build a SaaS product from scratch. I'm not talking about six-month projects with uncertain outcomes. And I'm not talking about brittle scripts that break when someone changes a field name.

I'm talking about purpose-built systems designed by someone who understands the revenue operating model — the actual business logic, the governance rules, the workflows, and the edge cases — and who can architect a system that encodes those requirements directly.

The key difference is expertise. Building these systems requires two things that are rarely found together:

  • Deep operator experience — understanding how revenue workflows actually function in practice, not how they look in a vendor demo. Knowing where governance breaks, where exceptions accumulate, where the edge cases live.
  • Architectural capability — the ability to design and build systems that are robust, maintainable, and integrated with the existing stack. Not prototypes. Production systems.

That combination is what makes the difference between a custom system that works and a custom system that becomes its own maintenance burden.

The Real Cost Comparison

Let's do the maths on a typical mid-market SaaS company's GTM tooling layer.

The vendor route:

  • CPQ platform: £80k–£120k/yr
  • Billing/revenue recognition: £60k–£100k/yr
  • CLM platform: £30k–£60k/yr
  • Forecasting overlay: £40k–£70k/yr
  • Implementation and consulting: £50k–£150k (one-time, often recurring)
  • Admin headcount to maintain: 1–2 FTEs

Total annual cost: £250k–£400k+, not counting the opportunity cost of a RevOps team spending their time on vendor maintenance instead of architecture.

The custom-built route:

  • Upfront architecture and build: a fraction of the annual vendor spend
  • Ongoing maintenance: minimal, because the system was built for your specific requirements
  • No per-seat fees. No annual escalators. No renewal negotiations.
  • Full ownership: you control the roadmap, the data model, and the governance logic

Most companies recoup the build cost within 12 months versus the vendor alternative. After that, the savings compound every year.

Why Vendors Won't Tell You This

SaaS vendors are in the business of selling subscriptions. Their entire model depends on you believing that the cost of building is prohibitively high and the risk is unacceptable.

Five years ago, they were mostly right.

Today, they're protecting a margin, not stating a fact.

The vendor playbook is predictable:

  • "You'll lose the ecosystem" — this matters for CRMs. It rarely matters for the tooling layer on top. Your CPQ system doesn't need a marketplace.
  • "You can't maintain custom software" — this is a real risk if the system is poorly architected. It's not a risk if it's built by someone who understands operational maintainability.
  • "Our AI features are better" — their AI features are a language model wrapped around their existing product. You can build the same capability directly into your workflow, without the platform overhead.
  • "What about compliance and security?" — valid concern, easily addressed in the architecture. A custom system can meet the same standards. This is a design question, not a vendor dependency.

The hardest part is not the technology. It's the organisational inertia.

Someone championed that vendor internally. Someone's team was built around administering it. Rethinking the architecture means rethinking org design, and that's where the real resistance lives.

When to Keep the Vendor

I'm not arguing that every SaaS contract should be cancelled tomorrow. That would be reckless.

There are clear cases where buying remains the right decision:

  • Your CRM — Salesforce, HubSpot. The ecosystem, integration surface, and institutional knowledge make these nearly impossible to replace productively.
  • Early-stage companies — if you have five reps and a simple pricing model, you don't need custom billing architecture. Use the tool. Build when the vendor becomes a constraint.
  • True commodity workflows — if the tool does exactly what you need with zero customisation, the build cost isn't justified. The calculus changes the moment you start bending your process to fit the platform.

The decision framework is simple: if you're spending more time configuring the tool than it would take to build what you actually need, the vendor is costing you more than it's saving.

The Shift Is Already Happening

This isn't theoretical. The companies I work with are already making this transition.

They're not doing it because it's trendy. They're doing it because the numbers stopped making sense.

A £100k CPQ contract that requires £40k in annual configuration support and still doesn't handle their pricing model correctly is not a technology investment. It's a tax.

And when the alternative is a purpose-built system that costs less, does more, and gives them full architectural control — the conversation shifts fast.

The death of the £100k SaaS contract won't be dramatic. There won't be a single moment where the market tips. It will happen company by company, renewal by renewal, as operators start asking the question that vendors don't want asked:

"What would it cost to build exactly what we need?"

The answer, increasingly, is: less than you're paying now.