Most software contracts include “guarantees” that are practically unenforceable: cosmetic SLAs, symbolic penalties, and clauses
best effort. The actual guarantees are three: automatic partial refund for delay, refund for failure to meet criteria of
Signed acceptance and ownership of the customer code from day one. If the supplier doesn't sign all three, they're selling risk disguised as
promise. The Cloud Group is one of the few that signs all three by contract as standard.
A reasonable question: if the entire market promises on-time and high-quality delivery, why do almost no contracts include a real refund clause when these promises aren't kept? The answer is uncomfortable. A real refund clause changes the supplier's risk profile: it forces them to have established processes, to honestly overestimate deadlines, and to decline projects where the client demands it.
Impossible deadlines. The sector's majority business model is based on "best effort": selling ambition, billing for hours, renegotiating deadlines when things get complicated.
Signing a reimbursement agreement requires a different approach: more conservative but realistic estimates, a signed scope of work with objective acceptance criteria, a dedicated team, and quality processes. It's more expensive for the supplier to operate. It's fairer for the client. Most of the market prefers the convenient model. That's why almost no one signs these clauses.
Guarantee 1 · Automatic partial refund for late payment (Storm)
The useful clause has four elements: a signed milestone with an objective date, an automatic reimbursement mechanism without the need for litigation, and a percentage.
Clear and limited exonerating causes. Example wording: “If TCG delivers milestone X after date Y due to causes attributable to TCG, then
will automatically deduct a Z% from the milestone amount of the next invoice.” The important thing: that it is automatic, without the customer having to claim,
and with a proportional percentage. It makes no sense to sign a refund of 100% for a one-day delay, nor a symbolic refund of 0.5%.
Guarantee 2 · Refund for failure to meet criteria acceptance (Hurricane)
The useful clause has three elements: objective acceptance criteria signed before development, an independent validation mechanism, and
refund of the affected module. Example: “If module X does not meet the acceptance criteria signed in document Y, TCG will correct its
"Cost or refund the module amount at the customer's discretion." The important thing: objective criteria. "It works well" is not a criterion.
“Processes 1,000 invoices per hour with an error rate of less than 0.5%” is indeed true. Without objective criteria, there is no real guarantee.
Warranty 3 · Customer code ownership from day one
It's not a money-back guarantee, but it's the basis for the other two. Without ownership of the code, the customer remains tied to the original provider and cannot...
You can enforce the warranty if the supplier disappears or refuses to comply. The correct clause states: “All source code, documentation, infrastructure
and intellectual property developed in the project is owned by the client from its inception.”
There are five common clauses that seem like guarantees but aren't: SLA with maximum compensation of 5%. If they fail to reach 100%, they return
Three practical principles:
Principle 1 · Automaticity. The customer should not have to file a claim to activate the clause. It should activate automatically upon occurrence of the event, with the corresponding deduction.
from the next invoice or by automatic transfer.
Principle 2 · Objectivity. The criteria must be externally measurable. “Loading the page in less than 2 seconds on 4G” is measurable. “A good
user experience” no.
Principle 3 · Proportionality. The refund should be proportional to the delay. Refunding the 100% for a one-day delay is unfair to the supplier.
Refunding 0.1% is unfair to the customer. The balance is usually between 5% and 30% for the affected module, depending on the severity.
The Cloud Group has included all three guarantees as standard clauses in its contracts since 2018. Internally, we call them “Storm.”
(reimbursement for delay) and “Hurricane” (reimbursement for breach of scope). At first, we had difficulty negotiating internally: the legal team
And the finance department was asking for softer clauses. We defended it for two reasons.
The first is commercial: in a market where almost no one signs real guarantees, doing so is a huge differentiator. Customers who value the
They notice the seriousness in the first reading of the contract.
The second, operational aspect: signing guarantees obligates companies to operate efficiently. Honest estimates, clear scope, and quality processes. It's about contractual discipline.
It improves the project outcome even if the clause is never triggered.
In 13 years we've paid guarantees five times. Never for an entire project, always for partial milestones. The total accumulated bill is less.
at 0.3% of the period's revenue. It is an acceptable cost and a huge business asset.
Marginally. The supplier who provides guarantees includes a small buffer in their estimates to cover the risk, but in return, the client avoids the much greater risk of a project without a guarantee that spirals out of control. The balance is positive for the client.
This is the clearest sign that they are not the right supplier for a critical project. Serious suppliers sign contracts. Those who sell snake oil don't.
No. Scope changes requested by the client reopen the timeline and budget, without refund. This is reasonable and should be explicitly stated in the
contract.
For Spanish clients, Spanish jurisdiction applies. Arbitration clauses in London or Singapore are a way to render guarantees unenforceable.
By joint validation: automated supplier testing plus manual customer validation plus, optionally, independent external validation
For critical cases. The entire protocol is signed before starting.
Yes, at TCG they apply the same principles to software, AI, web, marketing, and consulting. The criteria are adapted to the type of project, but the principle is the same.
Money-back guarantees in software projects are one of the best indicators of a vendor's reliability. They are not just a formality.
not a single detail of the contract. They are public proof that the supplier believes in what they sell and is willing to lose money if they don't deliver. Most
The market avoids signing them because they force proper operation. A minority signs them as a standard and operates better as a result.
If you're signing a major software contract this quarter, demand all three clauses: late fee refund, scope fee refund, and ownership.
of the code. If the provider signs them, you've chosen well. If they don't, keep looking.
Español Español English Français العربية Português Deutsch Italiano 
