A £75K pricing vendor and a £45K CDP vendor replaced with systems we built, own, and continuously improve. Here's when building beats buying.
Every SaaS vendor in your stack is a recurring tax on your margin. That statement is not anti-vendor — it is arithmetic. A £75K annual contract is not a one-time investment. It is £75K this year, £75K next year, and £82K the year after that when the vendor raises prices because they know migration is painful and you are locked into their data format.
At the UK fashion e-commerce retailer where we ran a £6.4M transformation programme, the SaaS stack had grown organically over five years. Twenty-plus integrated platforms, each solving a narrow problem, each with its own contract, its own data model, its own API quirks, and its own annual price increase. Nobody had ever audited the total cost against the total value delivered.
When we did that audit, two vendors stood out immediately. A pricing optimization vendor charging £75,000 per year, and a customer data platform vendor charging £45,000 per year. Combined: £120,000 annually for two systems that operated as black boxes, shared no data with each other, and delivered results that could not be independently verified.
We replaced both. The in-house systems we built are better, cheaper, and — critically — they talk to each other.
The pricing vendor provided markdown recommendations for owned stock. Their model was trained across their entire client base — a generic algorithm applied to a specific business. The client could not see the model, could not modify the logic, and could not explain to the board why any particular product was priced the way it was.
Three specific failures prompted the replacement.
No consignment logic. The vendor's system was designed for owned inventory. The client operated a marketplace with 196 sellers and approximately 1,600 consignment products that required fundamentally different pricing — two-way adjustments (markdowns for zero-sellers, markups for fast movers) on a daily cadence. The vendor could not do this. The client's merchandising team was pricing consignment stock manually, using spreadsheets.
No promotional awareness. The vendor's recommendations did not account for active discount codes, flash sales, or email promotions. Products were frequently double-discounted: a vendor-recommended 15% markdown layered on top of a 20% site-wide code, resulting in an effective 32% discount on a product that needed, at most, a 15% markdown. This conflict was invisible in the vendor's dashboard because the vendor did not ingest promotional data.
No feedback loop. Recommendations were generated weekly and pushed to the client's Magento platform. There was no mechanism for the model to learn from the outcomes. A recommendation that resulted in a sellout within 24 hours (suggesting the markdown was too deep) generated no signal back to the vendor's system. The same pricing error would repeat the following week.
We replaced it with two purpose-built engines — a warehouse engine running weekly across 15,000+ products and a consignment engine running daily across 1,600 products — plus a real-time monitor with 7 automated checks. The result: +77% revenue, +80% units, +72% gross profit by week five.
The CDP vendor provided customer segmentation and email triggers. For £45,000 per year, the client got: recency-based segments, basic purchase history lookups, and automated email triggers for cart abandonment and post-purchase flows. Standard features that come built into most modern email platforms.
What the vendor could not do was the one thing that mattered most: discount sensitivity scoring. The CDP could tell you who bought last week. It could not tell you who would buy at full price next week. It could not identify the 90,000 customers who were being offered unnecessary discounts. It could not run churn prediction with survival analysis. It could not score customers on a four-dimensional RFMD model.
We built the replacement on Snowflake (which the client already paid for) with dbt transformations. The marginal infrastructure cost is approximately £200 per month — £2,400 per year versus £45,000. The system processes 16.4 million customer profiles with 47 engineered features per customer. It feeds a four-tier discount strategy that identified £8.3M in margin protection.
The economics are not even close.
Curious what your margin opportunity looks like?
Free Tool
How much margin are you leaving on the table?
Answer 6 questions. Get a personalised margin estimate in under 2 minutes.
Take the Free Margin AuditThe financial savings — £120K per year in eliminated vendor costs — are meaningful but not transformational. The real value is in what becomes possible when two previously siloed systems share a data model and a feedback loop.
When the pricing engine and the CDP were separate vendors, they operated in parallel universes. The pricing vendor did not know which customers were discount-sensitive. The CDP vendor did not know which products were being repriced. The result was a constant stream of conflicts: products marked down for price-sensitive customers were simultaneously being promoted at a deeper discount to the full customer base, and full-price buyers were receiving unnecessary discount codes on products that the pricing engine had already optimally priced.
With both systems in-house, they share a common data layer in Snowflake. The CDP's discount tier for each customer constrains the pricing engine's voucher recommendations. The pricing engine's demand signals feed into the CDP's engagement features. When the pricing engine marks down a product, the CDP adjusts which customers receive that information — a Tier 1 full-price buyer sees it as a "new price" with no discount framing; a Tier 4 discount-dependent customer sees it as a "special offer."
This integration creates compounding effects that are impossible with a vendor stack. Each system makes the other more effective. After 12 weeks of shared operation, the combined revenue impact exceeded the sum of what either system would have achieved independently by approximately 23%. That delta — the integration premium — is the value that vendor salespeople never discuss, because their business model depends on you buying disconnected point solutions.
We are not absolutists. Not every vendor should be replaced. The decision depends on five factors.
1. Is the vendor solving a commodity problem or a differentiation problem? Payment processing is a commodity. Your business does not gain competitive advantage from building a custom payment gateway. Use Stripe, Adyen, or whoever offers the best rate. But pricing strategy and customer segmentation are differentiation problems. They are the systems that determine your margin. Outsourcing them to a generic vendor is outsourcing your competitive advantage.
2. Does the vendor's data model match your business model? The pricing vendor's model was built for direct-to-consumer brands with owned inventory. The client operated a hybrid model with owned stock and a consignment marketplace. The vendor could not model consignment pricing because their data model did not have a concept of two-way price adjustments. If the vendor cannot represent your business in their data model, their recommendations will always be approximate.
3. Do you need the systems to share data? If two vendor systems need to influence each other's outputs, you are paying for integration that will never work properly. APIs between vendors are lowest-common-denominator interfaces. They share IDs and basic attributes, not the rich feature sets that make each system effective. The integration tax — engineering time spent building and maintaining vendor-to-vendor integrations — often exceeds the cost of building one of the systems in-house.
4. Can you maintain it? An in-house system requires ongoing engineering. If you do not have the capability to maintain, monitor, and improve the system after it is built, the vendor may be the better choice. But "we don't have the capability" is increasingly a choice rather than a constraint. AI-assisted development has reduced the engineering cost of building and maintaining these systems by 60-70%. The maintenance burden is not what it was three years ago.
5. What is the exit cost? Vendors know that migration is painful, and they price accordingly. If you are in a multi-year contract with significant exit penalties, the build-vs-buy calculation needs to include the switching cost. In our case, both vendors were on annual contracts with 90-day notice periods. The switching cost was near zero.
The pricing and CDP replacements were the highest-value vendor changes, but they were not the only ones. Across the 13 tech cost reduction initiatives, we also replaced the monitoring stack, cancelled underused SaaS tools (project management, customer service integrations), reduced data warehouse and transformation costs, swapped the product information management system, and built an in-house AI replacement for the visual search vendor.
The total tech cost reduction workstream delivered £601K in annual value. Of that, £120K was the pricing and CDP vendor replacement. Another £240K came from cloud migration. The remainder came from contract renegotiations, tool consolidation, and database optimization that recovered 257GB of space and delivered query speedups of up to 59,000x.
Every business accumulates SaaS vendors over time. Each one made sense when it was adopted. Few are reviewed against alternatives once they are embedded. The annual vendor audit — not just checking if the contract is competitive, but asking whether the problem the vendor solves could now be solved better in-house — is one of the highest-ROI exercises any operations team can perform.
Two vendors costing £120K per year were replaced with in-house systems that cost approximately £5K per year to run, delivered measurably better results, and created a compound advantage through integration that the vendor stack could never provide.
The in-house pricing engine lifted revenue 77%. The in-house CDP identified £8.3M in margin protection. Together, they created a feedback loop that improved both systems' performance by 23% beyond what either achieved independently.
If you are paying six figures a year for vendor systems that cannot explain their recommendations, cannot model your specific business, and cannot talk to each other, the build-vs-buy calculation has probably shifted further than you think. AI-assisted development has made the "build" side dramatically cheaper. The integration advantage makes it dramatically more valuable. Our cloud cost reduction practice includes SaaS vendor audits as a core part of the infrastructure review.
We'll audit your vendor stack, identify the systems costing more than they should, and show you what an integrated in-house alternative would look like.
We go into businesses and make them permanently more profitable. Every initiative is EBITDA-tracked.