data.day

The Upgrade That Was Actually a Blockade

When a vendor removes a feature and puts it behind a paywall, it is not an update. It is a siege. Here is how to write contracts that forbid functional regression.

The Ransom Note in the Release Notes

The crisis began with a support ticket. “I cannot generate the monthly housing report,” the clerk wrote. “The button says ‘Upgrade to Unlock’.”

I walked to her desk. We had paid for this software for two years. The reporting function was the core reason for the purchase. I called the Account Manager.

“Ah, yes,” he said, his voice smooth. “We have streamlined our tiers. Advanced Reporting is now an Enterprise feature. You just need to sign this addendum for a 40% fee increase.”

“This is unacceptable to the municipality,” I replied. “You have effectively seized our data and are demanding a ransom to release it in the agreed format.”

“It’s just a new packaging strategy,” he insisted.

“No,” I said. “You have unilaterally redrawn the borders of our agreement. We do not negotiate with entities that annex our workflows overnight.”

The Dependency: The Shifting Sands of SaaS

The greatest weakness of Software as a Service (SaaS) is that we do not own the ground we stand on. We rent it. And the landlord has the power to change the locks while we are sleeping.

Vendors use “Continuous Delivery” as a weapon. They hook us with a feature set at a low price, wait for the dependency to harden, and then migrate critical features behind a higher paywall.

They frame this as “Innovation.”

  • Version 1.0: Includes API access.
  • Version 2.0: API access is now a “Premium Add-on.”

This is not innovation. It is a blockade. It creates a state of Operational Insecurity, where the Municipality cannot predict its own capabilities from one month to the next.

The Sovereign Choice: The “No Regression” Clause

We resolved the incident by threatening a public breach-of-contract lawsuit, but we ensured it would never happen again by changing our procurement treaty.

We now enforce the Functional Continuity Clause in every SaaS agreement:

“The Vendor guarantees that no feature, function, or API capability available at the Commencement Date shall be removed, degraded, or moved to a higher pricing tier during the Term. Any such reduction in functionality shall be considered a Material Breach, triggering an immediate pro-rated refund and a penalty-free exit.”

We also demand Version Freezing for critical infrastructure. We require the option to remain on the “legacy” version of the interface for up to 12 months if the “new” version disrupts our operations.

We do not object to the vendor making more money. But they must earn it by building new value, not by stealing the value we have already paid for.

FAQs

Can a vendor legally change the features after we sign?

Most standard Terms of Service allow them to 'modify the service at any time.' This is why we never sign standard terms.

How do we define 'functional regression'?

It is the removal or degradation of any capability that existed at the time of signature. If it worked yesterday, it must work tomorrow.

What if the feature is genuinely retired for security?

Then they must provide a functional equivalent at no cost. Security is not an excuse for extortion.