Software defects: securing and enforcing your rights
Whether there is a defect is decided against the agreed specification. Where the description of services is vague, a technical dispute turns into a problem of proof.
Most disputes about software are not about whether something fails but about what was owed. That is why the description of services decides the dispute more often than the error itself.
The stages of enforcement
Step 1: Establish what was owed
What was agreed, what follows from the purpose of the contract, and what is in the offer, the specification and the correspondence?
Step 2: Document and notify the defect
Error, environment, reproducibility and the time of reporting. The notice goes out in writing and is delivered provably.
Step 3: Demand cure
With a reasonable deadline and a clear statement of what counts as performed. Without this stage the further rights are usually not open.
Step 4: Further rights
Where cure fails, price reduction, rescission or termination and damages come into consideration, shaped differently depending on the contract type.
Two sides of the same dispute
On the customer side
- Record the agreed specification early and in writing
- Accept only with reservation where defects are known
- Document errors reproducibly rather than merely describing them
- Set deadlines instead of chasing informally
On the supplier side
- Anchor the customer duties to cooperate in the contract
- Provide for an acceptance procedure with criteria and deadlines
- Run change requests through the change procedure, not on the side
- Limit liability, but within the range that actually holds
How we support you
We act for both sides, though never in the same matter. Knowing both perspectives usually produces an early realistic view of how far a dispute can be carried and where a settlement is the cheaper route.
A project going off the rails?
We sort out the legal position before the next invoice arrives.
Get in touchFrequently asked questions
What role does acceptance play?
In a works contract it shifts the burden of proof. Before acceptance the supplier has to show that performance conforms. Afterwards you have to plead and prove the defect. Anyone accepting without reservation despite known defects regularly loses rights. The reservation therefore belongs in the acceptance record.
What should we document?
When which error occurred in which environment, how it can be reproduced, when it was reported and how the supplier responded. That chain decides the dispute later, not anyone assessment of whether the software is good.
Can we simply end the project?
Not simply. Depending on the contract type, setting a deadline, allowing cure and its failure are preconditions for rescission or termination. Skipping those stages puts you in breach instead. We assess which stage has been reached and what the next defensible step would be.