ContractsChoosing a vendorCode ownershipGDPR
Software development contract: the clauses to check
7 min read
A software development contract protects you through what it spells out: the scope and how it will be accepted, the price and how changes are handled, the rights in the code, the warranty, data protection, liability and the terms of exit. A contract that is vague on any one of these points is enough to turn an ordinary disagreement into a dispute.
This article walks through the clauses worth reading, in the order they tend to cause trouble in practice. It describes general principles, not the law of any one country, and it is not legal advice: have your contract reviewed by a lawyer in the jurisdiction that governs it, especially if the software is critical to your business.
Scope: what is ordered and what is not
Everything starts here. The contract should refer to a document describing what will be delivered: a specification, a feature list or, better, an agreed prototype showing the screens and user journeys. What is not described is not ordered, and will either be billed as extra or refused.
Three things to check:
- Explicit exclusions. Migrating data from your old tool, integrations with your ERP or accounting system, extra languages, training: written down, they prevent unpleasant surprises.
- Assumptions. Every estimate rests on assumptions (number of users, access to an existing API, availability of your staff). They belong in the contract, with what happens if they turn out to be wrong.
- Order of precedence. If the quote, the specification and the standard terms contradict each other, which one wins? The contract should say.
Our method to compare software development quotes shows how unstated assumptions explain most price differences.
Acceptance testing: how the software is signed off
Acceptance is the moment you confirm that what was delivered matches what was ordered. It is the most neglected clause and the one most often invoked in a dispute, because it usually triggers the final payment and the start of the warranty.
A solid contract provides:
- test scenarios agreed in advance, rather than an overall impression;
- an acceptance period of a set length, and what happens if you do not respond within it;
- a severity scale for defects (blocking, major, minor), with the rule that only blocking defects prevent acceptance;
- a signed acceptance record, with or without listed defects, and a deadline to fix those that remain.
If the project is delivered in stages, plan one acceptance per stage: each signed-off stage reduces the risk of the next one.
Price, change requests and schedule
The contract states whether the price is fixed for a defined scope or based on time and materials. The difference is explained in fixed price vs time and materials. Either way, check:
- the payment schedule: deposit, payments tied to accepted stages, final balance on acceptance;
- the change procedure: any change of scope goes through a written, priced change order signed before the work starts;
- the schedule and its conditions: a delivery date only binds the vendor if your own obligations (providing content, reviewing on time) are dated too;
- any late-delivery penalties, their cap and their exclusions.
Intellectual property and licences
Who owns the code is decided by the contract, not by who paid. In the United States and the United Kingdom, a transfer of copyright from a contractor must be in writing and signed. The contract should separate three layers: code written for you, the vendor's reusable components (usually licensed, not assigned) and open source dependencies (governed by their own licences). We cover the rules in detail in who owns the source code of custom software.
Warranty and maintenance are not the same thing
| Clause | What it covers | Who pays |
|---|---|---|
| Warranty | Defects, after acceptance | The vendor |
| Corrective maintenance | Defects, after the warranty | Maintenance agreement |
| Evolutive maintenance | New features | Quote or subscription |
| Operations | Hosting, backups, updates | As agreed |
For custom software between businesses, the warranty is mostly whatever the contract says it is: its length, the response times by severity and what it excludes. A defect is a departure from what was agreed; a request that changes agreed behaviour is a change request. The more precisely that line is written, the less it gets argued about.
Maintenance is a longer commitment, with its own service levels. If the vendor also hosts the application, the contract should say who monitors it, who applies security updates and how quickly incidents are handled.
Personal data: GDPR Article 28
If your users or customers are in the European Union, or your vendor is, data protection deserves its own clause. As soon as the vendor hosts your application or handles personal data on your behalf, it generally acts as a processor under the GDPR. Article 28 of Regulation (EU) 2016/679 then requires a contract that sets out the subject matter, duration, nature and purpose of the processing, the type of personal data and the categories of people concerned.
That contract must in particular require the processor to:
- process the data only on the documented instructions of the client;
- ensure that the people with access are bound by confidentiality;
- take the security measures required by Article 32;
- engage another processor (a hosting provider, for example) only with the client's written authorisation, passing on the same obligations;
- assist the client in answering requests from individuals and meeting its security and breach notification duties;
- delete or return the data at the end of the contract, at the client's choice;
- make available the information needed for audits.
These terms usually sit in a data processing agreement appended to the main contract. What the application itself must do is covered in our GDPR checklist for a business application.
Liability and its limits
Most contracts cap the vendor's liability, often at the value of the contract, and exclude indirect losses such as lost profits. This is standard and negotiable, but how far a cap will be enforced depends on the governing law. In England and Wales, for example, section 3 of the Unfair Contract Terms Act 1977 means that when one business deals on the other's written standard terms, a clause excluding or restricting liability for breach only stands if it satisfies a reasonableness requirement. Other jurisdictions have their own rules, which is one more reason to know which law governs your contract.
Look at what the cap covers and what it leaves out: data loss, breaches of confidentiality and intellectual property claims are often treated separately. Check subcontracting too: can the vendor hand part of the work to a third party, and will you be told? Our 12 questions to ask a software development company explain why this matters.
Exit: ending the contract cleanly
A relationship can end for good reasons: the project is finished, your strategy changes, the fit is not right. The contract should say what happens that day:
- term, notice period and grounds for termination;
- what you receive (source code or access to an escrow deposit, depending on the rights agreed, documentation, account access);
- an export of your data in a usable format;
- the vendor's help during the handover, and what it costs.
That is the subject of our article on your exit plan for custom software.
Other clauses not to skip
- Confidentiality: what each side may say about the project, and for how long after the contract ends.
- Non-solicitation of staff: common, worth reading for its length and scope.
- Governing law and jurisdiction: essential as soon as the vendor is in another country.
- Publicity: may the vendor name you as a client? This is negotiated, not a given.
Where LPR Studio stands
Our commitments depend on the model you choose and are written into each contract. The demonstration prototype remains our property: it is presented in a video call, not delivered. After that, rights in the code are defined case by case in the contract. With the subscription model, LPR Studio remains the publisher and operator of the application; with a fixed price, the price is set for a written scope. The three models are on our offers page and the way we work is on our approach page.
Where to start
The best contract rests on a scope both sides see the same way. At LPR Studio, the visual prototype is free and presented in a video call within 5 working days, wherever you are: it becomes the shared reference for the price, then for acceptance testing. Have the contract reviewed by your own lawyer before you sign.