You Paid for That Feature. Now Your Competitor Is Using It.

It usually happens at a trade show, or in a demo a colleague forwards. There, in your vendor’s sales deck, is the feature your team specified last year. The workflow your operations director designed. The reporting view you paid a five-figure invoice to have built.

It now has a marketing name. And the prospect it is being pitched to is one of your direct competitors.

One multi-site leisure business we spoke to reached this moment after years of steady investment. Their licence fee was modest, around £20k a year. Their change request spend was not: more than ten times that, year after year. The features they specified and funded appeared in the vendor’s product releases, and then in sales conversations with other operators in their market. Their conclusion was blunt: every pound of innovation spend was strengthening their competitors’ platform.

Why does your funded feature end up in the vendor’s product?

Because the contract says it can, and the economics say it must.

Start with the contract. Standard SaaS agreements assign intellectual property in the product, including all enhancements, to the vendor. It does not matter who requested the feature, who specified it, or who paid for it. A change request is not a commission; it is a contribution. You are paying to move your requirement up the vendor’s backlog, not to own the result.

Then the economics. A SaaS vendor’s entire model rests on building something once and selling it many times. A feature built for one customer and fenced off from everyone else is, to the vendor, dead weight: code to maintain with a market of one. The pressure to generalise your feature and release it to the whole customer base is structural. Every vendor faces it, and almost every vendor yields to it.

This is not a moral failing, and it is worth being clear about that. The vendor is doing exactly what their business model requires. We have written separately about the ethics of the vendor relationship, and the honest position is that nobody is behaving badly here. The dynamic is structural. But structural or not, the effect on you is the same.

What you contribute goes beyond money:

• Your ideas. The feature concepts that come from running your operation day to day.
• Your domain knowledge. The edge cases, the regulatory detail, the operational reality the vendor’s product team does not have.
• Your budget. The change request invoices that fund the development itself.

The vendor combines all three, wraps them in their brand, and takes them to market. Your market.

What happens when you are the anchor customer?

There is an acute version of this trap, and it catches the businesses that were the vendor’s earliest and biggest supporters.

A specialist franchise network found itself in exactly this position. They were the vendor’s first large customer, and their requirements had shaped the product from the start. As the vendor grew, they noticed the pattern had a heads-you-lose, tails-you-lose quality:

• Where their feature needs overlapped with other customers, their funding was building their competitors’ system.
• Where their needs were unique to them, the vendor had little commercial interest in building them at all.

A public sector transport operation had it worse. They were the founding customer of a niche scheduling product and effectively bankrolled its early development, contributing the ideas and the domain expertise that made it credible. The vendor then pivoted towards a broader market. Despite a substantial standing change budget, the operator watched the roadmap drift away from their use cases entirely.

Their reflection, years later, was that they wished they had built the system themselves, or at least taken an ownership stake, rather than gifting a decade of operational expertise to a supplier. We cover the full lifecycle of that relationship in a companion piece on the anchor customer trap.

At what point should change spend become ownership?

Here is the reframe that matters. The question is not “can we afford to build our own system?” It is “what is our change request budget actually buying, and would the same money buy more if we owned the result?”

Run the comparison honestly:

• Change spend on the vendor’s product buys features you do not own, delivered on the vendor’s timetable, released to your competitors, on a platform you could lose at the next renewal.
• The same spend on your own system buys assets on your balance sheet, a roadmap you control, and differentiation your competitors cannot subscribe to.

For years, the second option was priced out of reach for most mid-market operators. That has changed. Our recent proposals for large greenfield Azure builds are landing at 28 to 34% of what the same work would have cost before AI-augmented delivery, with full code ownership as standard (Q2 AI Velocity Report).

At that cost level, the arithmetic gets uncomfortable quickly. A business spending over £200k a year on change requests is, over three or four years, spending more than the cost of a complete custom build in the £150k to £350k range. The difference is that at the end of those years, the builder owns a system. The subscriber owns invoices.

If your change spend is a multiple of your licence fee, two resources will help you test the numbers:

• The AI-era SaaS replacement playbook covers when, why, and how to replace a SaaS product with custom software.
• The ROI guide for AI-augmented development gives you the cost model to run the comparison properly.

What should you do next?

Pull your last two years of change request invoices and total them. Then read your contract’s IP clause and confirm who owns what those invoices paid for. For most SaaS customers, the answer to the second question makes the first number look very different.

If you want a second pair of eyes, book a consultation and we will review what your change request spend is actually buying, and what the same budget would buy if you owned the roadmap.