We use cookies to improve your experience on our site. Cookies strictly necessary for the service to function are always active. Learn more about our cookie policy
A software development agreement governs a bespoke development engagement, where a developer (an individual contractor or a software house) builds custom software for a client, as distinct from licensing off-the-shelf or SaaS software. The central legal question it must answer clearly is ownership of the resulting intellectual property: under English law, absent an express written assignment, a developer commissioned as an independent contractor (rather than an employee) retains copyright in the code it writes, even though the client has paid for the work — this is the reverse of many clients' assumptions and is the single most common source of dispute in bespoke development relationships. The agreement should therefore include an explicit assignment of copyright (and, where relevant, other IP rights) on payment, together with a waiver of moral rights under the Copyright, Designs and Patents Act 1988, since moral rights cannot themselves be assigned. As a contract for services, the Supply of Goods and Services Act 1982 implies a term (for a business client) that the work will be carried out with reasonable care and skill. The agreement should also address open-source components: whether the developer may use third-party open-source libraries, and under what licence terms, since some open-source licences (notably strong copyleft licences) can affect the client's ability to keep the resulting software proprietary. When to use it: whenever a business commissions bespoke software, an application, a website build, or custom integration work from an external developer or agency, whether fixed-price or time-and-materials. Parties: the client (who commissions and pays for the work) and the developer (an individual contractor or a company, delivering the development services). Key clauses: scope of work and specification (ideally referencing a detailed technical specification as a schedule); milestones, acceptance testing and acceptance criteria; fees and payment schedule (fixed price or time-and-materials); intellectual property assignment on payment, plus moral rights waiver; use of open-source or third-party components; warranties (fitness for purpose, no infringement of third-party rights); a post-delivery bug-fix or warranty period; confidentiality; and liability limitation subject to the Unfair Contract Terms Act 1977 reasonableness test. Pitfalls to avoid: assuming ownership of the code transfers automatically because the client paid for the work — it does not, without an express assignment; failing to define objective acceptance criteria, which leaves 'is it finished' open to dispute; and not addressing third-party open-source components, which can create unexpected licensing obligations for the client's finished product.
Client's registered name
Client's registered address
Developer's name or registered name
Developer's address
Description of the software to be developed
Reference to the detailed technical specification
Development milestones and delivery dates
Acceptance testing criteria and period
Fee structure (fixed price or day rate)
Total fee or day rate
Payment schedule
Policy on use of open-source components
Post-delivery bug-fix warranty period
Developer's liability cap
Date of signature