This section explains the commercial and operational issues that software contracts need to settle: scope, change, acceptance, ownership, liability, support, data protection, termination and exit. It does not provide wording for a particular transaction; the signed documents need current legal review.
Decision summary: Use the contract set to connect scope, evidence, remedies, ownership, data, service continuity and exit rather than relying on a headline clause.
How to use this guidance safely
For “Contracts and Legal”, this is commercial guidance, not a substitute for advice on a particular contract. Definitions, schedules, governing law and the interaction between clauses can materially change the outcome. Record the operational requirement first, then have the wording reviewed for the actual transaction.
What to include in a web development contract
A web development contract exists to make sure both sides understand what is being built, by whom, for how much, and what happens when things change. Without these fundamentals recorded clearly, disputes become far more likely and far harder to resolve.
The core elements every contract should address are scope, deliverables, acceptance, payment, ownership, liability, support, termination and governing law. Each of these deserves its own clause rather than being bundled into vague language.
Scope needs to describe the system being built in enough detail that a new supplier could pick up the document and understand the boundaries. This means referencing a specification or requirements document rather than trying to cram every feature into the contract itself. The contract should state which document forms the scope, what version, and what date.
Deliverables should list what the business will actually receive at each stage: source code, database schemas, deployment scripts, access credentials, documentation. Vague references to "the application" leave room for argument about whether infrastructure configuration or third-party licence keys are included.
Acceptance criteria tie payment to verified results. The contract should specify who tests, how long they have, what constitutes a pass or fail, and what happens when issues are found. Without this, a supplier can claim completion while the business considers the system unusable.
Payment terms need to align with milestones that are objectively verifiable. Paying a large proportion before any working software exists concentrates risk on the buyer. Paying everything at the end concentrates risk on the supplier. A staged structure tied to accepted deliverables distributes risk more evenly.
Change control is frequently overlooked. The contract should explain how requests outside the original scope are handled: who estimates the impact, who approves it, and whether the timeline shifts. A process that feels bureaucratic at the outset prevents the far more painful arguments that arise when changes are made informally and then disputed.
Software support SLA: what a business should ask for
A support service-level agreement defines what happens after the build is complete and accepted. Many businesses treat this as an afterthought, only to discover that "support" in the contract means something very different from what they assumed.
The first distinction to understand is between defects and changes. A defect is something that does not work as described in the accepted specification. A change is something new or different. Support SLAs typically cover defects; changes are usually billed separately. The contract should draw this line explicitly, because grey areas cause the most friction.
Severity levels matter. Not every issue demands the same response. A production outage affecting all users is fundamentally different from a cosmetic issue on a rarely used screen. The SLA should define severity tiers, and for each tier specify the target response time (how quickly someone acknowledges the issue), the target resolution time (how quickly it is fixed), and the escalation path if those targets are missed.
Coverage hours need stating clearly. Does support operate during business hours only, or around the clock? Which time zone? What happens if an issue is reported on Friday evening and the SLA assumes Monday-morning response? These details matter for operational systems.
Exclusions deserve close attention. Common exclusions include issues caused by third-party services, problems arising from unauthorised modifications, and anything related to hardware the business controls. Some of these are reasonable; others may be so broad that they effectively void the SLA for common scenarios.
Reporting is often absent from SLAs but matters for accountability. The business should have the right to receive regular reports showing response and resolution times against the agreed targets. Without this, there is no practical way to enforce the SLA or identify a deteriorating service.
Finally, consider what happens when the support period ends. Can the business renew on the same terms? Are there automatic price increases? Is there a notice period? Exiting support without a plan can leave a system with no safety net.
Intellectual property terms in software contracts
Intellectual property clauses determine who owns what when the project is finished. This sounds straightforward but contains several traps that businesses frequently miss.
The most important question is whether the business will own the source code outright or receive a licence to use it. Outright ownership means the business can take the code to any developer in future. A licence means the business can use the software but the supplier retains ownership and may restrict what the business can do with the code. Some suppliers will not assign ownership at any price; this needs establishing before the contract is signed, not afterwards.
Third-party components complicate ownership. Most web applications use open-source libraries, frameworks and packages. The business cannot own code that the supplier does not own. The contract should acknowledge this reality and list the major third-party components, their licences, and any obligations those licences impose (for example, attribution requirements or copyleft conditions).
Pre-existing IP is another common point of confusion. If the supplier has built similar systems before, they may reuse code, patterns or modules they already own. The contract should distinguish between code created specifically for this project, which the business might own, and pre-existing code, which the supplier retains. The business needs to understand what it is actually getting.
Derivative works need consideration. If the business owns the delivered code but the supplier retains ownership of underlying frameworks or modules, can the business modify the delivered code without infringing the supplier's retained rights? This should be addressed explicitly rather than left to interpretation.
For UK businesses, moral rights also warrant a mention. Under UK law, authors retain certain moral rights regardless of ownership, including the right to be identified as the author. These are usually waived in commercial contracts, but the waiver should be present.
Liability and warranty clauses in software agreements
Liability clauses allocate financial risk between the parties. Warranty clauses define what guarantees the supplier provides about the software's quality. Both are heavily negotiated and both contain language that can significantly affect the business's position if something goes wrong.
Liability caps are standard in software contracts. The supplier will want to limit their total liability to a multiple of the contract value, or to the fees paid in the preceding twelve months. The business will want the cap to be higher, or uncapped for certain categories of loss. A common compromise is an uncapped cap for breaches of confidentiality or intellectual property infringement, with a capped limit for everything else.
Exclusions of liability deserve careful reading. Suppliers often seek to exclude liability for indirect or consequential losses, loss of profits, loss of data, and business interruption. For a business relying on a custom system, some of these exclusions may be unacceptable. The question is not whether exclusions are standard (they are) but whether the specific exclusions leave the business bearing risks it cannot insure or absorb.
Warranty periods define how long the supplier guarantees the software will conform to the specification. A typical warranty might last between three and twelve months after acceptance. During this period, the supplier fixes defects at no additional charge. After the warranty expires, defect fixes fall under the support SLA or are billed separately.
The definition of a defect matters. Does the warranty cover only outright failures, or does it also cover performance that falls short of specified targets? If the specification says the system should handle a certain number of concurrent users, and it does not, is that a warranty defect or a performance tuning issue? The contract should be clear.
Warranties usually exclude issues caused by the business's own modifications, misuse, or failure to maintain the hosting environment. These exclusions are reasonable in principle but can be drafted so broadly that they become a catch-all excuse. The business should ensure the exclusions are specific and tied to identifiable causes.
NDAs for software development projects
Non-disclosure agreements protect confidential information shared during a project. They are common in software development because the business often needs to share commercial strategies, customer data structures, integration details and internal processes with the supplier.
The first practical question is whether an NDA is actually needed at the proposal stage. Many suppliers will not sign an NDA before seeing enough information to decide whether they want the work. A sensible approach is to share a general description of the project without revealing the specific commercial advantage, then sign the NDA once both sides are genuinely engaged.
Mutual NDAs are more common than unilateral ones in software projects. The supplier may have proprietary tools, frameworks or methodologies they do not want disclosed. A mutual NDA protects both sides and is less likely to cause friction at the outset.
What counts as confidential information needs defining. The NDA should cover information that is clearly marked as confidential, or that a reasonable person would understand to be confidential given the circumstances. It should explicitly exclude information that is already public, independently developed, or received from another source without restriction.
Duration is a frequent negotiation point. Some NDAs last indefinitely; others expire after a set period, commonly two to five years. For trade secrets and core commercial strategies, indefinite protection may be appropriate. For operational details that become less sensitive over time, a fixed duration is more practical and easier for the supplier to accept.
NDAs have practical limitations. They are only as effective as the willingness and ability of the other party to enforce them. For highly sensitive information, the business should also consider technical controls: restricting access on a need-to-know basis, using secure sharing platforms, and avoiding sharing raw customer data where anonymised samples would suffice.
Data protection clauses in software contracts
Where a supplier processes personal data on the documented instructions of a business, the contract must reflect the controller–processor relationship and include the required UK GDPR terms. Other activities may create controller-to-controller or joint-controller relationships, so the parties should map roles by processing purpose rather than apply one label to the whole service.
The contract must state that the supplier will process personal data only on the business's documented instructions. This prevents the supplier from using the data for its own purposes, such as training AI models or improving its own products, unless the business has explicitly agreed.
Security measures need describing at a level that allows the business to assess whether they are adequate. Vague references to "appropriate technical measures" are not sufficient. The contract should reference a specific security standard or attach an appendix describing the measures in place. The business should review these measures with current guidance in mind, as expectations change over time.
Sub-processor arrangements require attention. If the supplier uses other parties to process the data (for example, a cloud hosting provider or a payment processor), the contract should either list approved sub-processors or require the supplier to notify the business before engaging new ones. The business needs the ability to object if a sub-processor's arrangements are inadequate.
Breach notification terms should specify how quickly the supplier will inform the business if a data breach occurs, what information they will provide, and what cooperation they will offer in responding to the breach and meeting the business's own notification obligations to the Information Commissioner's Office.
Data return and deletion at the end of the contract are often neglected. When the relationship ends, the business needs its data back in a usable format, and it needs confirmation that the supplier has deleted copies they no longer need. The contract should specify the format of data return, the timeframe, and the evidence of deletion the supplier will provide.
Data protection law changes and is interpreted differently over time. The contract should include a commitment from the supplier to comply with current UK data protection law, not just the law as it stood when the contract was signed. For specific compliance questions, businesses should consult current ICO guidance or seek legal advice.
How to negotiate a software development contract
Effective negotiation starts well before the contract is on the table. The business should understand its own priorities: which clauses are essential, which are desirable, and which it can concede in exchange for movement on something that matters more.
Reading the contract line by line is non-negotiable. Supplier contracts are drafted to protect the supplier. This does not make them unreasonable, but it does mean they will not naturally reflect the business's interests. Relying on verbal assurances that "we never actually enforce that clause" is a mistake. The written terms are what matter if the relationship deteriorates.
Common negotiation points include liability caps, IP ownership, warranty duration, termination rights and change-control processes. On each of these, the business should know its fallback position before entering the negotiation. If the supplier refuses to assign source-code ownership, for example, the business needs to decide whether an exclusive perpetual licence is acceptable or whether ownership is a deal-breaker.
Raising every clause as a major issue undermines credibility. Prioritise the points that genuinely affect risk and value. A supplier is more likely to engage constructively on a focused list of genuine concerns than on a document returned with red ink on every page.
Documenting agreed changes matters. Verbal agreements to amend clauses should be captured in writing before the contract is signed. A side letter or amended clause is straightforward to produce; relying on memory or email threads is not.
Timing affects leverage. Once the business is dependent on the supplier and the project is underway, negotiating power shifts. The most important contractual terms should be settled before work begins. If the supplier pressures the business to sign quickly, that is a signal to slow down, not speed up.
What to do when a contract dispute arises
Disputes in software projects typically fall into a few categories: the system does not match what was agreed, the project is late, one side believes a change is included while the other believes it is extra, or the support is inadequate. Regardless of the cause, the initial response should follow a structured approach rather than an emotional one.
The first step is to read the contract. Not skim it, but read the specific clauses that relate to the disagreement. Acceptance criteria, change-control processes, liability provisions and dispute-resolution clauses all become relevant. Many disputes that feel intractable are actually addressed by terms the parties agreed to but forgot.
Document everything from this point forward. Every conversation, every email, every version of the software. If the dispute escalates, the party with better records is in a stronger position. Notes from phone calls should be written up and confirmed in writing.
Communicate in writing, clearly and without exaggeration. State what the problem is, which contractual term is relevant, what outcome the business is seeking, and by when. Avoid attributing motive or making accusations. The goal at this stage is resolution, not punishment.
Escalation within the supplier's organisation often helps. The project manager may be defensive about their work; a director may take a more commercial view of the cost of a prolonged dispute. The contract should specify escalation paths, and using them is a normal part of dispute resolution, not an act of aggression.
If direct negotiation fails, the contract's dispute-resolution clause dictates the next step. Many contracts require mediation before litigation. Mediation is typically faster and cheaper than court proceedings, and it allows both sides to reach a pragmatic settlement rather than having a solution imposed by a judge who may not understand software.
Litigation is the last resort. It is expensive, slow, and unpredictable. For most business-system disputes, the costs of litigation bear no sensible relationship to the value of the claim. The threat of litigation is often more useful than litigation itself, but making threats without the willingness to follow through damages credibility.
Termination clauses and exit rights
Termination clauses determine how the relationship ends, and exit rights determine what the business walks away with. Together, they are the most important contractual provisions for reducing long-term dependency on a single supplier.
Termination for cause allows either party to end the contract if the other breaches a material term and fails to remedy it within a specified period. The contract should define what counts as a material breach and how long the breaching party has to fix it. If the remedy period is too long, the business may be forced to continue paying for a supplier who is not delivering. If it is too short, the supplier may face termination for a minor issue that could have been resolved.
Termination for convenience allows one or both parties to end the contract without a specific reason, usually with a notice period. Not all contracts include this. If the business wants the flexibility to end the engagement because its needs have changed or it has lost confidence in the supplier, it should negotiate a convenience-termination right with a reasonable notice period.
Transition assistance is critical and often missing. When the contract ends, the business needs the supplier's cooperation to move to a new provider or bring the work in-house. This may include handing over documentation, providing access to systems, making the source code available in a buildable state, and responding to reasonable questions from the replacement team. The contract should specify the duration and scope of transition support and whether it is included in the fees or billed separately.
Data handover needs its own provision. The business must get its data back in a structured, usable format. The contract should specify the format (for example, standard SQL exports, CSV files, or API access), the timeframe, and who bears the cost. If the data is locked in a proprietary format that only the supplier can read, the exit right is effectively meaningless.
Source-code escrow is sometimes suggested as a safety net. Under an escrow arrangement, the supplier deposits the source code with a third-party escrow agent, and the business gains access to it if the supplier fails to meet certain conditions (such as insolvency). Escrow sounds reassuring but has practical limitations: the code may be outdated, it may not build without the supplier's environment and configuration, and there may be no one available to maintain it. Escrow is a last-resort measure, not a substitute for strong termination and exit rights in the contract itself.
Post-termination restrictions should be reasonable. The supplier may ask for a clause preventing the business from hiring their staff for a period after termination. These clauses are enforceable only if they are reasonable in duration, geography and scope. The business should resist restrictions that go beyond what is necessary to protect the supplier's legitimate interests.
Contract points to settle before signature
- Identify which signed document controls if schedules, proposals or emails conflict.
- Distinguish ownership, licence rights, practical access and third-party restrictions.
- Define acceptance evidence, remedies, liability allocation, exit assistance and governing law explicitly.
- Obtain current legal advice for the actual parties and transaction before relying on contractual wording.
Primary guidance checked for this edition
Sources for “Contracts and Legal” were checked on 22 July 2026. Recheck the applicable rules, product documentation and contractual terms before implementation because these can change after the review date.