This is Part 5 of our 6-part series on the dangers of SCM Vaporware. Read Part 4: Operational Paralysis: When Phantom SCM Software Breaks the Supply Chain for the operational impact, and conclude with Part 6: Building Genuine Resilience.
Buying supply chain software is a legal act as much as a technical one. The contract is what you are left holding if the software never works.
Part 2 covered how to spot vaporware before you sign. This part is about the terms that protect you if you sign anyway — because sometimes the decision is made above you, and the contract is the only place left to put a guard.
This article is not legal advice. Use it to brief your own counsel.
The Danger of Standard Vendor Contracts
The first mistake is signing the vendor’s own paperwork as written.
Their agreements are drafted to protect them. The language around dates is usually soft. The definition of “working” is usually vague. The limit on what they owe you if it fails is usually low. Many include a line saying you should not buy on the strength of features that are not released yet — which is exactly how vaporware is sold.
Sign that as it stands and you have agreed, in advance, that the promises made in the room do not count.
Forging Your Contractual Armor: Essential Clauses
Four terms do most of the work. Your counsel and your buying team need to put them in before signature, not after the first missed date.
1. A price for missing the date
Vaporware lives on dates that move. So name them, and attach a cost to missing them.
Write down each feature, what it must do, and the date it must do it by. Then name the consequence:
- money back from fees already paid;
- a charge for each day late, taken off what you owe next;
- the right to walk away at no cost.
The point is not to collect the penalty. It is that a vendor who cannot build the feature will say so before signing rather than after.
2. Pay for what passes a test, not for what is promised
Never pay the whole licence up front. A vendor who already has the money has no reason to finish.
Tie each payment to a test. Your team runs it, on your data, against the specification in the statement of work. It passes or it does not. If it does not, the payment waits.
3. Say what the software must actually do
Most contracts say the software will perform “substantially in accordance with its documentation”. That is too loose, because the documentation may be marketing.
Replace it with the specifics your operation needs. Name the records it must read, the system they come from, how many there are, how long it may take, and what the output has to be. “The software will optimise inventory” is not testable. “The software must read this file from this system and return this, within this time” is. Use your own numbers, taken from your own volumes — not the vendor’s.
4. Put the source code in escrow
If you are buying a new product from a small vendor, there is a real chance the vendor does not survive the project.
Ask for a software escrow agreement. The vendor lodges the source code with a neutral third party, and updates it as the software changes. If they fail to deliver, fold, or break the contract, the code is released to you. It does not give you a working product. It does stop the whole investment from disappearing with the company.
Navigating the Legal Fallout: Breach of Contract and Fraud
If the money is already spent, there are two routes, and both are slow.
Breach of contract is the usual one. If your statement of work named the features and the dates, and the vendor missed them, you can sue to recover the fees and the costs of the failed rollout. How well that goes depends almost entirely on how specific that document was.
Fraudulent misrepresentation is the harder route. It applies if the vendor knew the software did not exist and had no way to build it. You have to prove what they knew, which is difficult. Damages can be higher, but so are the costs and the time.
Neither route gets the work done while it runs. Plan the operational fallback in parallel with the legal one.
Conclusion: Procurement as a Defensive Strategy
The contract is not paperwork at the end of the process. It is the only part of the purchase you control.
Refuse the standard terms. Tie money to tests your own team runs. Name the dates and what missing them costs. A vendor with working software will accept all three. A vendor without it will start explaining why those terms are unusual — which is the most useful thing you will learn in the whole negotiation.
Conclude our series and learn how to align procurement with real operational needs in Part 6: Building Genuine Resilience: Choosing Proven SCM Technologies Over Vaporware.
Frequently Asked Questions (FAQ)
What is a “Safe Harbor” statement and why is it dangerous?
It is a disclaimer saying that a vendor’s statements about the future are not promises, and that you should only buy on what exists today. It is dangerous because the sales pitch is usually about the future, and this clause says the pitch does not count.
Can we sue a vendor for the “Opportunity Cost” of buying vaporware?
Rarely with success. Direct costs such as fees and consulting are recoverable. Lost sales or lost market position are hard to prove, and most vendor contracts exclude that kind of loss outright.
Why is it important to tie payments to milestones?
It moves the risk back to the vendor. If the software cannot pass your test, the vendor does not get paid, and the spending stops before it grows.
What should be included in a Statement of Work (SOW)?
Specifics, not marketing. Which records the software reads, from which system, in what volume, how fast, and exactly what it must return. Who tests it, and what counts as a pass. The more precise the document, the easier it is to show a breach.
How do we test a feature before a payment is released?
Write the test before the contract is signed, and put it in the contract. Use your own data and your own people. Run the test on the version the vendor delivers, not on a demo environment they control.
