Software development goes wrong: when can you hold your supplier liable?

As a business owner, you rely on reliable software. You invest time, money and trust in an IT supplier — and then it turns out that the end product does not work as agreed. What are your rights? When can you claim compensation? And what happens if you forget to formally give notice of default to your supplier? A ruling by the Supreme Court of 17 July 2026 concerning a software dispute that had dragged on for years offers business owners important lessons on liability, breach of contract and the limits of exoneration clauses in IT contracts.

A software project that went completely off the rails

Imagine this: you commission a specialist software supplier to completely overhaul an existing business application. You enter into a framework agreement, pay millions and work together for years. But the software does not function properly. Quality reports show that the source code is of such poor quality that a complete rewrite is unavoidable. Your company eventually runs into financial difficulties and ceases trading.

This is exactly what happened to an entrepreneur involved in a software company that had commissioned a major IT service provider to further develop a sports application. The application — originally used by top clubs and recommended by international sports organisations — needed to be migrated to a modern technology environment. After years of collaboration, mounting debts and the source code being locked away, the results proved downright disappointing. The source code received the lowest possible quality rating.

Ultimately, the company was declared bankrupt and the claims against the IT supplier were transferred to the entrepreneur himself. This marked the start of a legal battle that made its way through the district court, two courts of appeal and, on two occasions, the Supreme Court. The central question was: had the IT supplier breached its contractual obligations, and if so, was the entrepreneur actually entitled to claim damages?

The framework agreement: an obligation to use best endeavours or an obligation to achieve a specific result?

In software projects, a framework agreement is often chosen: an overarching contract under which separate work orders are subsequently issued. This offers flexibility, but also creates legal risks. One of the biggest pitfalls is the distinction between an obligation to use best endeavours and an obligation to achieve a specific result.

Under an obligation of best efforts, the supplier undertakes to provide sufficiently qualified effort — but does not guarantee a specific end result. Under an obligation of result, the supplier guarantees a specific, pre-defined product.

In this case, the framework agreement stipulated that the IT supplier had an obligation of effort, but was nevertheless responsible for the quality of the software to be supplied. At the same time, responsibility for the budget, planning and deadlines lay with the client. Furthermore, the parties worked according to the so-called RUP methodology: an iterative approach in which the client continuously issued new work orders and the specifications of the end product were never fully fixed.

Practical lesson: In a framework agreement, set out as specifically as possible what you, as a business owner, expect from the supplier. Define not only the approach, but also measurable quality requirements and milestones. The vaguer the agreements, the more difficult it is to prove a breach of contract later on.

Breach of contract and default: two requirements you must not overlook

When a contracting party fails to fulfil its obligations, this is referred to as breach of contract. However, the mere fact that someone has failed to fulfil their obligations does not automatically entitle you to compensation. For this, default is also required: the debtor must have been formally given notice of default.

The general rule under Dutch contract law is that default only occurs after you have sent the other party a written notice of default. In this notice, you give the supplier a reasonable period to still fulfil their obligations. If they fail to do so, they are in default and you can claim compensation.

There are exceptions where default occurs by operation of law — that is, without a notice of default — but these are by no means always applicable in such situations.

The strict deadline: when is a deadline really a deadline?

One of the exceptions where default occurs automatically is the expiry of a strict deadline: an expressly agreed date or period within which the performance must be delivered. If that deadline is not met, the debtor is immediately in default — you do not need to send a separate notice of default.

In this case, the IT supplier had undertaken in December 2006 to rectify certain defects in the software within six months. The business owner argued that this was a strict deadline. The court did not agree with him on this point.

The court ruled that this undertaking formed part of the ongoing discussions between the parties regarding the further development of the software. As no clearly defined end product had been agreed upon and development was continually building on previous versions, it could not be inferred from this undertaking that it constituted a strict, peremptory deadline.

· Practical lesson: A verbal or informal commitment regarding a delivery date is rarely legally binding as a strict deadline. Do you want to be certain that a deadline is legally enforceable? Then state explicitly and in writing that the deadline is strict and that failure to meet it will result in immediate default.

Complaints about software: when is complaining enough?

Business owners sometimes assume that repeated complaints about poor software quality are sufficient to hold the supplier liable. In practice, this is not the case. The court emphasises that a notice of default serves a clear purpose: the supplier must understand that you are giving them a final chance and that, otherwise, you will take legal action.

A persistent series of complaints, bug reports and requests for rectification – however frustrating – does not constitute a notice of default. The other party must be able to deduce from your communication that the situation is no longer acceptable to you and that you will invoke their contractual liability if they fail to perform within a specified period.

In this case, the contractor had never sent a formal notice of default. Whilst the letter from his company dated October 2010 contained numerous complaints, it ended with a request to discuss compensation. There was no notice of default setting out a specific deadline for rectification or warning of legal consequences.

· Practical lesson: Do you feel that a project is systematically going off the rails? Then send a written notice of default in good time. Do not wait until the damage has already been done. A solicitor can help you to draft that letter in a legally correct manner.

Can a reliance on the absence of a notice of default be deemed unacceptable?

Sometimes, according to the standards of reasonableness and fairness, it may be unacceptable for a supplier to rely on the fact that they were never served with a notice of default. This is a safety valve in the law: if the rigid application of the formal rules were to lead to an unjust result, the court may correct it.

In practice, however, this criterion is applied strictly. Where professional parties have deliberately entered into a commercial agreement and know what they can expect from one another, the court will not readily rule that a claim that no notice of default was given is unacceptable. The business owner in this case argued that the IT supplier had withheld an internal quality report concerning the poor source code from his company. Nevertheless, the court ruled that this was not sufficient to set aside the defence of absence of default, because the supplier had continued its work — even after the report had been published.

Breach of contract and tort: two paths that do not always coincide

A key aspect of this case concerns the relationship between a claim based on breach of contract (attributable failure to perform a contract) and a claim based on tort. Business owners sometimes believe that, if they lose their breach of contract proceedings, they can always still seek compensation for their losses through a tort claim.

The Court of Appeal had ruled that this was not possible in this case, because the business owner had relied on exactly the same facts for his tort claim as for the breach of contract claim. No breach of contract, therefore no tort.

The Supreme Court put a stop to this. The highest court ruled that the dismissal of the claims for breach of contract — solely on the grounds of the absence of default — does not automatically mean that the claims for tort are also inadmissible. This is because the lapse of time is a requirement for damages in a breach of contract, but not in a tort claim. The court should therefore have assessed that claim separately.

This is a legally relevant distinction: even if your breach of contract proceedings fail due to a procedural requirement such as the absence of default, you may still be able to recover your losses through a claim for tort — provided the facts justify it.

· Practical lesson: In a dispute with an IT supplier, always consider both grounds: breach of contract and tort. Base both claims on all relevant facts and circumstances, even if those facts overlap to some extent.

Exoneration clauses in IT contracts: read the small print

Virtually every IT contract contains an exoneration clause: a provision that limits or excludes the supplier’s liability. In this case, the IT supplier’s general terms and conditions applied. These stipulated that compensation for direct loss was limited to a maximum amount of €1,250,000 and that indirect loss was entirely excluded.

Such clauses are, in principle, legally valid, unless:

  • there is intent or gross negligence on the part of the supplier;
  • invoking the clause is unacceptable according to standards of reasonableness and fairness.

In this case, the business owner failed to demonstrate that there had been wilful misconduct or deliberate recklessness, so the exemption clause remained in force.

· Practical lesson: Negotiate the liability exclusion clause before signing an IT contract. Try to increase the liability limit, limit the exclusion of indirect damage, and stipulate that the clause does not apply in the event of serious shortcomings. Once signed, it is much more difficult to get out of it.

What does this mean for you as an entrepreneur?

This case illustrates how a software project spanning several years, even if the quality delivered is clearly substandard, can become legally extremely complex if the formal requirements have not been met. The key lessons for entrepreneurs working with IT suppliers:

  • Make specific agreements. Set out quality requirements, milestones and acceptance criteria in writing. Avoid working on the basis of vague framework agreements without a clear end result.
  • Send a notice of default in good time. Do not wait until your business has already suffered serious damage. Seek legal advice in good time and formally serve the supplier with a notice of default as soon as you establish that they are consistently failing to meet their obligations.
  • Explicitly set out strict deadlines. If you want a deadline to be legally binding, state explicitly that the deadline is strict and that default occurs by operation of law if it is exceeded.
  • Combine breach of contract with tort. Invoke both grounds and substantiate them as fully as possible with all relevant facts and circumstances.
  • Assess exemption clauses critically. Have your supplier’s general terms and conditions reviewed before signing. Negotiate the liability limit and the exclusions.
  • Document everything. Keep emails, complaint records, meeting minutes and quality reports. In legal proceedings, written evidence carries great weight.

Q&A: frequently asked questions about liability in software development

What is a notice of default and when do I need one?

A notice of default is a written demand in which you formally give notice of default to your supplier. In it, you give them a reasonable period of time to fulfil their obligations. Without a notice of default, your supplier cannot, in most cases, be deemed to be in default, and without default, you are not entitled to compensation for breach of contract.

What is the difference between an obligation of effort and an obligation of result?

In the case of an obligation of effort, the supplier promises to make every effort, but does not guarantee a specific result. In the case of an obligation of result, they do guarantee a specific end product. In IT contracts, an obligation of effort is often chosen, which makes it more difficult to prove breach of contract.

Can I take action against a supplier without giving notice of default if they fail to meet a deadline?

You can, but only if that deadline has been expressly agreed as a strict deadline. An informal commitment or a schedule discussed jointly by the parties is rarely considered a strict deadline in legal terms. Always set this out in writing and in no uncertain terms.

What is an exoneration clause and can I challenge it?

An exoneration clause limits or excludes the liability of a contracting party. You can challenge the invocation of such a clause if there is wilful misconduct or gross negligence on the part of the supplier, or if invoking it is unacceptable according to standards of reasonableness and fairness. The latter, however, is a strict standard, particularly between professional parties.

What is the difference between breach of contract and tort?

Breach of contract is the failure to fulfil a contractual obligation. Tort is an independent legal basis outside the contract. The advantage of a tort claim is that it does not require a period of default. If your claim for breach of contract fails due to a lack of default, you may still be able to obtain compensation through a claim for tort.

Can I recover my losses if my IT supplier has supplied faulty software?

Yes, in principle you can — but you must meet the legal requirements: there must be an attributable breach (breach of contract), your supplier must have been put in default or default must have arisen by operation of law, and you must have actually suffered damage that is causally linked to the breach. Seek guidance from a solicitor specialising in business law or IT law.

What should I do if my software project goes off the rails?

Document all complaints and shortcomings carefully. Keep all correspondence. Engage a solicitor in good time. Send a formal notice of default setting a reasonable period for rectification. Also consider whether you wish to terminate the contract and what types of damages you can claim. The sooner you seek legal advice, the stronger your position will be.

Questions?

Do you have any questions regarding this article? Our solicitors are on hand to advise you! Please contact one of our solicitors by email, by telephone or fill in the contact form for a no-obligation initial consultation. We’d be happy to help you find a solution.


About the author

Bert Gravendeel

Intellectual property & IT and ICT law