Software Development Disputes: Resolving Failed Bespoke Software Projects
When a bespoke software project fails, the outcome depends on what your contract says about scope, delivery dates, acceptance and limits on liability. How frustrated either side feels carries little weight. This article explains how software development disputes arise under English law, what you can recover, who owns the code and data, and what to do before you end the contract or start a claim.
Failed software projects rank among the most damaging disputes a small business can face. You have spent money and built operational plans around a system that does not work. The developer says you kept changing your mind and never paid for the extra work. Both accounts usually contain some truth, so each side needs to examine the evidence carefully before anyone sends a termination notice.
Why Bespoke Software Projects Break Down
Most disputes come from a few common causes. Identifying yours early shapes your strategy and your costs. A single dramatic event rarely causes the problem. More often, what you thought you were buying and what the developer thought it had agreed to build drift apart over time.
A vague or shifting specification. If the discovery phase never became a signed specification, nothing sets out what the developer had to deliver. Courts look for an objective record of what each side promised. Where that record is missing, both sides’ positions weaken and you will probably need expert evidence.
Missed deadlines and slipping launch dates. Delay is the most common reason people end these contracts. Many contracts do not make delivery dates strict enough to let you end the contract for lateness, and many give no clear remedy for late delivery. In Topalsson v Rolls-Royce Motor Cars, the developer missed every milestone date, both the original dates and the revised ones. The court held that the revised dates were binding because the developer had prepared them and the customer had approved them. It also rejected the developer’s argument that the customer had got in the way of the work.
Change Control, Testing and Payment Problems
Changes that nobody prices or agrees. Agile development, where the developer builds in short stages and the plan evolves along the way, works only if every change is recorded and priced. Disputes often arise over which document governs, the original proposal or a later implementation plan. Record each change in a signed variation that states its price and its effect on delivery dates.
Testing that never ends. Payment usually depends on the customer accepting the software. Disputes then arise over whether defects were serious and whether the customer unreasonably refused to sign off. Weak acceptance criteria turn a technical question into an expensive legal one.
Payment and cash flow pressure. Developers stop work when invoices go unpaid, and customers stop paying when deliverables slip. Both steps carry risk. A developer that stops work without a contractual right to do so may commit a serious breach, which lawyers call a repudiatory breach. That gives the customer the right to end the contract and claim the cost of a replacement system. A customer that withholds payment without a clear right can end up in breach instead.
What Your Contract Actually Promises
Start with a close reading of the contract documents. These include the statement of work (the document that describes the work and the price), the specification, the change control log and the service levels (the agreed performance standards). In practice, the documents that decide the outcome are often the ones the parties treated casually, such as email approvals of completed stages of work or informal sign-off of designs.
If you agreed a fixed price for a fixed list of features, the developer carries the delivery risk and must produce software that meets that list. An agile contract promises something different: a defined process, a resourced team and delivery against a backlog (a list of tasks) that changes as the project goes on. Many contracts sit between the two. They describe an agile process but keep fixed-price and fixed-date wording, and that mismatch often leads to disputes.
Implied Terms and Misrepresentation Claims
If the contract says nothing about quality, the law still requires a business supplying services to act with reasonable care and skill under section 13 of the Supply of Goods and Services Act 1982. That standard works like a negligence test. It does not guarantee a working system, and the courts accept that complex software is rarely free of defects. A defect alone does not prove a breach, so this route is harder to prove than a failure to meet an agreed specification.
Sales presentations, demonstrations and tender responses often promise features that the finished product lacks. If a false statement of fact persuaded you to sign the contract, you may have a claim for misrepresentation alongside your claim for breach of contract. Both Topalsson and Drax Energy Solutions v Wipro involved allegations of misrepresentation. Contracts often contain entire agreement and non-reliance clauses, which aim to shut these claims down. They deserve close examination, because they are not untouchable. Section 3 of the Misrepresentation Act 1967 requires them to pass a reasonableness test.
Who Owns the Code, the Data and the Repository
Ownership is where failed projects cause the most lasting damage. If you cannot lawfully use or develop the software, you lose far more than the fees you paid. The legal default surprises most clients.
Paying for bespoke software does not make you its owner. Under section 90(3) of the Copyright, Designs and Patents Act 1988, copyright in code written by an external developer stays with the developer unless the developer transfers it to you in a signed written document. Without written terms, you usually have an implied licence, which is a right to use what you paid for. In some cases a court will go further and treat you as the owner where the arrangement requires it, but the outcome is uncertain and you should not rely on it. Code that your own employees write in the course of their employment is different. Copyright in it belongs to you as their employer automatically, unless an agreement says otherwise.
Transfer of ownership on payment. A well-drafted agreement transfers all intellectual property rights in the bespoke elements to you in writing when you make the final payment. It should expressly cover the source code (the instructions the developer writes to build the software), database structures, design documents and build scripts (the files that assemble the software). Without that clause, the developer can lawfully refuse to hand over the source code and may reuse it for other clients.
Source Code Access, Escrow and Handover
Access to the source code. Many customers discover mid-dispute that they only ever received a working copy of the software. The source code sat in an online repository (a storage system for code) in the developer’s own account. Contractual rights to that repository, or an escrow arrangement, make the difference between hiring a replacement developer quickly and rebuilding from scratch. Under escrow, a neutral third party holds a copy of the code and releases it when set conditions are met. Those conditions often focus on the developer’s insolvency, so escrow may not help in a dispute about quality or delay.
Third-party and open-source components. Developers build bespoke systems from existing libraries of code, and each library carries its own licence conditions. Some libraries are open source, which means anyone can use them under published terms. Some licences restrict commercial use. Others require you to disclose code built on top of them. A schedule listing each component and its licence protects you from inheriting a compliance problem you cannot see.
Handover that depends on conditions. If the contract makes handover depend on payment or another step, the courts will hold you to it. In Transparently v Growth Capital Ventures, the customer ended the contract and asked the court for an urgent order (an interim mandatory injunction) requiring the developer to hand over the source code and related materials. The application failed. Under the contract, handover was conditional on the customer settling unpaid invoices and issuing shares to the developer, and the customer had not issued the shares, so it could not show a serious case for the order. The court declined to rewrite the bargain, leaving the customer without software that it said its business depended on.
Proving Breach and Recovering Your Losses
The sum you can recover usually depends more on the limits and exclusions in your contract than on how much disruption you suffered.
Your most valuable types of claim are usually the money you paid the failed developer, the internal costs you wasted on the project, and the extra cost of getting the system built elsewhere. In Topalsson, Rolls-Royce claimed around 20 million euros for replacement software and lost profits. The court assessed its damages for the termination at just under 8 million euros before applying the contractual cap.
Exclusion clauses can decide whether your most valuable claim survives at all. In Soteria Insurance v IBM (formerly CIS General Insurance v IBM), the High Court found that IBM had wrongly ended the contract. It still held that the customer could not recover its wasted expenditure (money spent on the project that the breach made worthless), which it put at around 122 million pounds, because the contract excluded loss of profit, revenue and savings. The Court of Appeal reversed that decision in 2022. It held that wasted expenditure is a different type of loss from lost profit, so the exclusion did not cover it, and it entered judgment for just over 80 million pounds after applying the contractual caps. The same drafting issue arises on a much smaller project.
Liability Caps in Software Development Disputes
A liability cap usually sets the real ceiling on what you can recover, and its exact wording often decides the outcome. A cap on a supplier’s total liability can catch every type of claim, including payments for delay, and courts expect clear wording before they read a cap as cutting across a party’s ordinary rights. If one side contracted on the other’s written standard terms, a cap or exclusion must also meet the reasonableness test in the Unfair Contract Terms Act 1977. Courts are slow to interfere where two businesses of similar bargaining power agreed the term.
One cap can cover every claim. In Drax, the contract capped the developer’s liability at 150 per cent of the charges paid or payable over the previous twelve months (estimated for a full year where the claim arose in the first year). The court held that this was a single cap covering all claims together, not a separate cap for each claim. That reduced the ceiling to around 11.5 million pounds against a claim of about 31 million pounds. Whether your contract contains one cap or several comes down to drafting, and it can matter more than the strength of your case.
Cross-Claims, Interest and the Cap
Each side’s cap applies before any deduction. In Topalsson, the trial judge deducted the sums owed to the developer first and then applied the cap, which left the full 5 million euros payable. In November 2024, the Court of Appeal reversed that approach. Where a clause caps each party’s total liability, the cap applies to each party’s liability separately, and you deduct the cross-claims only afterwards. Applying the 5 million euro cap to the developer first, then deducting the smaller sum Rolls-Royce owed it, left just over 4.2 million euros payable to Rolls-Royce.
Interest may fall outside the cap. The Court of Appeal’s main ground was that the developer had never pleaded this argument and could not raise it late. It added, as an alternative view, that interest on late payment fell outside the cap on that contract’s wording, because the contract made interest the sole and substantial remedy for late payment. No earlier case decided the point directly, so this is no general rule and you need to read each cap and interest clause on its own terms. Interest can build up over years of delay and litigation and can rival the capped sum, which cuts both ways depending on which side of the invoice you sit.
Working Out What Your Claim Is Worth
Take a 150,000 pound fixed-price build. You have paid 90,000 pounds, the cap is 100 per cent of the charges paid, and replacing the system costs 220,000 pounds. Your realistic ceiling is 90,000 pounds, not the 220,000 pounds you lost, before legal costs. Running that arithmetic before you issue a claim often changes the commercial strategy.
Deadlines matter too. Contracts often set strict notice periods, defect notification windows and time limits for raising claims, and missing one can end an otherwise good claim. The general time limit for a breach of contract claim is six years from the breach. That sounds generous, but evidence, staff and system versions degrade quickly. If the contract has an escalation or dispute resolution clause, ignoring it can cost you in legal costs.
Resolving Software Development Disputes Without Destroying Value
Ending a contract is a legal act with serious consequences. Treat it as a decision, not a negotiating move. The order of the steps below tends to widen your options.
Stabilise the position first. Secure copies of any source code you are entitled to, export your data, and keep the project record, including emails, task and bug-tracking records, meeting notes and test results. An expert will rely on this material later, and it becomes much harder to obtain once relations break down. If credentials or repositories are at risk, you can ask the court for an urgent order or for early disclosure of documents before a claim starts. Transparently shows that an urgent order for handover of code requires a clear contractual right.
Take advice before serving notice. Withholding payment, suspending work or walking away without a clear contractual right can turn you from the innocent party into the party in breach. If you end the contract validly, you can recover the cost of getting the system built elsewhere, subject to the cap. A defective notice can undermine your claim and invite a counterclaim for unpaid fees. Developers face the same risk. IBM found this when a court held that its withdrawal from a contract was a wrongful repudiation, meaning a serious breach by IBM.
Pre-Action Steps in Software Development Disputes
Follow the correct pre-action steps. Software disputes can go to the Technology and Construction Court, the specialist High Court division for technology and construction cases, and Practice Direction 60 expressly covers software claims. Before you issue a claim, you must follow the court’s pre-action process. The Construction and Engineering protocol may or may not apply to a pure software dispute, because its examples focus on architects, engineers and surveyors. If it applies, it calls for a brief summary of the claim and a meeting between the parties. If not, the Practice Direction on Pre-Action Conduct applies instead. It still expects a clear letter setting out your claim, a proper response and consideration of mediation.
Take mediation and expert input seriously. You can use mediation at any stage. It is usually faster, cheaper and more private than litigation, and any agreement can be recorded in a binding settlement. The courts can now order parties into dispute resolution, and refusing to take part without good reason can lead to costs penalties. An independent expert’s view of what the developer actually delivered often breaks a deadlock, because both sides tend to overestimate their technical case.
Aim for a commercial outcome. A negotiated handover of source code, a fee credit, a fixed-price plan to fix the software or a phased exit will often serve your business better than a judgment obtained years later. A settlement also protects confidentiality and preserves relationships in what is often a small supplier market.
How the Jonathan Lea Network Can Help With Software Development Disputes
We act for customers and developers in software and technology disputes. These include development failures, licensing and scope disagreements, source code and IP ownership conflicts, data access problems and breaches of confidentiality. We start by reviewing the contract, specification and project record. We then give you a candid view of the merits, calculate your claim against the relevant caps and exclusions, and pursue the route most likely to achieve a commercial result. That route might be negotiation, mediation or another form of alternative dispute resolution, or litigation where it is justified.
Every project and contract is different, so outcomes, costs and timescales depend on the documents, the evidence and the other side’s conduct. Nothing here is advice on your specific situation. Advice taken before you serve a notice or withhold a payment usually improves your position and reduces your exposure. If your bespoke software project has stalled, has gone well over budget, or has left the code and data outside your control, we would be glad to talk it through with you.
Frequently asked questions: software development disputes
Most software development disputes come from a few common causes. These include a vague or shifting specification, missed deadlines and unpriced changes. Testing that never ends and payment pressure are common too. A single dramatic event rarely causes the problem. More often, what you thought you were buying and what the developer agreed to build drift apart. Identify the cause early, because it shapes your strategy and your costs. Not automatically. Copyright in code written by an external developer stays with the developer. That changes only if they transfer it to you in a signed written document. Without written terms, you usually have an implied licence to use what you paid for. Code written by your own employees in the course of their employment belongs to you, unless an agreement says otherwise. Check whether your agreement transfers the intellectual property to you when you make the final payment. Yes, in some cases. Without a clause transferring ownership, the developer can lawfully refuse to hand over the source code. It may also reuse the code for other clients. If the contract makes handover depend on payment or another step, the courts will hold you to it. In Transparently v Growth Capital Ventures, the customer’s urgent application for the code failed for this reason. Read the handover terms before you act. Under escrow, a neutral third party holds a copy of the code. It releases the code when set conditions are met. Those conditions often focus on the developer’s insolvency. So escrow may not help in a dispute about quality or delay. Contractual rights to the online repository can make the difference between hiring a replacement developer quickly and rebuilding from scratch. Check what your contract actually gives you. Not always. Delay is the most common reason people end these contracts. However, many contracts do not make delivery dates strict enough to let you end the contract for lateness. In Topalsson v Rolls-Royce Motor Cars, the court held that revised dates were binding. The developer had prepared them, and the customer had approved them. Take advice before you serve notice, as a defective notice can undermine your claim. Possibly. A false statement of fact may have persuaded you to sign the contract. If so, you may have a claim for misrepresentation as well as breach of contract. Contracts often contain entire agreement and non-reliance clauses that aim to stop these claims. However, these clauses must pass a reasonableness test under section 3 of the Misrepresentation Act 1967. So examine them closely rather than assuming they end your claim. It depends mainly on the limits and exclusions in your contract. Your most valuable claims are usually the money you paid, wasted internal costs and the extra cost of a replacement. However, a liability cap usually sets the real ceiling. For example, the cap may be the charges paid. If you paid 90,000 pounds, that may be your limit even if replacement costs more. Run this arithmetic before issuing a claim. Not necessarily. In Drax Energy Solutions v Wipro, the court held that the contract had a single cap covering all claims together. That reduced the ceiling to around 11.5 million pounds against a claim of about 31 million pounds. Whether your contract has one cap or several comes down to the drafting. It can matter more than the strength of your case, so check the exact wording early. Stabilise the position first. Secure copies of any source code you are entitled to, export your data and keep the project record. That includes emails, task and bug-tracking records, meeting notes and test results. An expert will rely on this later, and it becomes harder to obtain once relations break down. Then take advice before withholding payment or serving notice, so you stay the innocent party. Software disputes can go to the Technology and Construction Court, a specialist division of the High Court. Before you issue a claim, you must follow the court’s pre-action process. Where it applies, the general Practice Direction expects a clear letter setting out your claim. It also expects a proper response and consideration of mediation. The courts can now order parties into dispute resolution. Refusing to take part without good reason can lead to costs penalties.
Contact us
We provide most enquiries with an indicative scope of work and fee estimate, based on the information you share. We aim to respond within one working day.
In the same email you will be invited to arrange a 20-minute complimentary, no-obligation video consultation, should the proposed scope of work and fee estimate be of interest. This initial discussion is designed to better understand your requirements, refine the scope and ensure our approach is fully aligned with your objectives, at the end of which we will email you a definitive formal fee estimate to consider and approve.
Where you would prefer to receive initial advice and guidance from the outset, or where a short introductory call would not be the most appropriate starting point, we may instead recommend a 2.5-hour fixed-fee appointment, starting from £700 + VAT. This enables us to review the information you provide, discuss your situation with you and provide considered, tailored advice at an early stage.
To make an enquiry, please email us at wewillhelp@jonathanlea.net, complete our contact form, or call us on 01444 708640.
VAT is charged at 20%.
This article is intended for general information only, applies to the law at the time of publication, is not specific to the facts of your case and is not intended to be a replacement for legal advice. It is recommended that specific professional advice is sought before relying on any of the information given. © Jonathan Lea Limited.