It’s been 17 years since SI published its first major series on generic insider tips back in 2009 where we gave you a lot of advice that more-or-less still stands today if you want to safely acquire software. In our preamble, we overviewed what those 11 pieces of advice were then, and summarized the 6 major differences that affect how you apply that advice today so you can continue to make the right decisions when acquiring software in the age of AI Hype and exaggerated I2O claims. In the last two parts we addressed the first four pieces of advice and how they have evolved over the years. Today, we continue.

Read the contract

Remember what we’ve been telling you since the beginning.

• There’s no such as a free lunch.
  Free modules? Free support? Free training? Not likely! Either it’s included in the price, is being offered as an enticement to lock you in for a fixed term, it’s being offered in an attempt to divert your attention away from a complex SLA that benefits the vendor and not you, or it’s being offered to distract you from the lack of remuneration when they screw up and cost you time and money.
• Don’t get screwed by the new release (or new functionality).
  As sure as the sun rises in the east, the vendor will come out with a new release, module or offering not long after you’ve bought the current version and expect you to pay a large tranche of money to get (part of) it. You may get offered a small “upgrade” or “new buyer” discount, but you’ll pay, then pay again, and pay again, and again for as long as you own the software. If you’re paying an annual license fee for SaaS, make sure the upgrades are all inclusive.
• Don’t get fooled by the license fee in disguise.
  Many traditional enterprise software platforms have a clause buried deep in the SLA that requires you to pay the annual maintenance fee, or lose the right to use the software altogether even though you have years left on the contract. That’s not a maintenance fee, that’s a license fee. Make sure the maintenance fee is a real maintenance fee for support and bug fixes.
• Don’t get satiated by the presence of an SLA.
  The majority of Service Level Agreements (SLAs) are designed for one purpose — and one purpose only — to give you a false sense of security that will cause you to overlook the fact that the wording insures that the vendor will be able to keep your money for the length of the contract, no matter what. Your average SLA will run for a dozen or more pages with lots of fancy wording around “Level 1” problems, “Level 2” problems, and so on with detailed text spelling out your responsibilities and consequence-free reprieve time for the vendor while you lodge your complaint and fill out the necessary documentation. Unless the SLA allows you to terminate the contract any time the vendor fails to deliver against the SLA, with no penalty, and complete exports, it’s useless.

And then realize that, today, you also have to keep in mind the following:

• Minimum license and maintenance increases tied to inflation are BS.
  Software depreciates with time, it doesn’t appreciate. All code has a limited life-span before it becomes technical debt. Give or take 3-5 years for an average app, 5 to 10 for an enterprise app, with life-spans shrinking all the time. In other words, the code should get cheaper over time unless there is a minimum functionality improvement and minimum service and support levels guaranteed.
• AI Priced Separately … Even When It Should Not Be.
  Some providers are realizing just how costly it’s becoming to run those BS Gen-AI LLMs they built their functionalities on, especially third party ones that have to considerably jack up their token costs over the next couple of years just to break even, and are making you responsible for the third party AI costs. Right now it’s still pretty cheap, so you might look this over, but there are two problems with this. One, if it’s required for the vendor’s product to work, they should be paying for it, not you — that’s what license and maintenance fees are for. Two, letting them pass the buck gives them no incentive to be efficient about their use of AI and could result in your system becoming unaffordable to use in a few years. If the AI is a completely optional plug-in layer, such as a conversational interface to the analytics product that summarizes the dashboard (where you could read the data off the screen yourself, translate it to plain English, and make the pretty powerpoint slide yourself for your mathematically challenged executives), that’s one thing. If the analytics is built on LLMs, that’s a whole other thing — and cost won’t be your only concern.
• Standard limitations of liability don’t work in the AI world.
  You should be responsible for use, but not responsible for any unguarded actions taken by the AI that result in loss, damage, or illegal activity. (After all, most vendors aren’t actually implementing guardrails and just wrapping third party LLMs and claiming they are safe because the third party vendors say they are safe.) But once you give their “AI Employee” the right to auto-buy and auto-pay, that AI Employee can buy illegal drugs on the dark web, send the payment to a terrorist group, and leak your bank details to a scam group. But if you accept the standard verbiage the vendor will give you, you assume all liability for the actions taken by their software. DO NOT!
• Fixed user licenses are a fixed drain on your finances.
  If you have to buy on a user-based license model (and you really should be looking for enterprise), you need the ability to shift licenses around as needed, so that you don’t have unused licenses, as well as the ability to fluctuate in a range. You might have to buy a minimum, but you shouldn’t have to buy 1000 if, at any given time, you will only need 700.
• Data Ownership Clauses
  Suppliers will wholeheartedly agree you own your data, tout that you retain ownership of your data that is yours and yours alone in the sales pitches, and then hide clauses that allows them to use any and all of your data to train any and all of their models and even use it to train third party solutions that will profit off it AND leak it to the world — does that sound like data ownership to you?

Forego the Escrow

Finally, remember that the escrow is pretty useless because you don’t have what it takes to even operate the software, yet alone maintain it. And it’s not something you can just throw on a consultancy because it takes a long time to figure out Million plus line applications and get a team up to speed to maintain them. And it’s significantly more costly than switching to an entirely new application and hiring a data migration team to extract the data from the application about to go offline and feed it into a new application.

That’s why, as we’ve repeatedly said, the most important clause in your (Procure)Tech (SaaS) Contract is the one that allows you to get a complete extract of your data at any time with a single click.

However, in today’s world, that should be a minimum. In order to get up and running again quickly, you don’t just need your data, you need your configurations — the business rules that define your processes, the logic that defines your exception handling, the specific analytics that your users need, and the integration configurations the app relied on. You should be able to get a complete export of all of the rule definitions and logic as well as your data. (Since the AI Hype era has finally brought about the importance of contexts, with the introduction of MCP, you need the context to migrate quickly. The I2O players are adopting MCP, and it will soon be quick and easy to migrate to a new application if you need to if you can export all of your data and rules.