Software development agreement for an agency

A software development agreement for an agency building software for clients, drafted from the developer's side for a fixed fee of £995 in five working days.

Share

Software development agreement for an agency

A software development agreement for an agency or development house, drafted from the developer's side, covering scope, specification and the method of working, acceptance and change control, payment by milestone or stage, intellectual property and when it passes, third-party and open source components, warranties, defects and the warranty period, and liability, termination and non-solicitation. £995, delivered in five working days.

Buy now, £995

A development agency is paid to build something that does not yet exist, and the agreement is where it protects itself against the ways that goes wrong: a scope that keeps growing, acceptance that never comes, payment that waits for a launch the client controls, and IP that the client claims before it has paid. The agreement has to define the work and how it will be done, set acceptance and change control, tie payment to milestones, pass IP on payment and no earlier, and limit the warranty and the liability to what the fee supports. I draft that agreement for a fixed fee of £995, delivered in five working days.

Who this is for

Software development agencies, app developers, web development studios and freelance developers in England and Wales building software for business clients under a project contract, whether fixed-price, agile or a mix.

What matters in a development agreement for an agency

Scope, specification and the method of working

The agreement should attach a specification or a statement of work, say how detailed it is and how gaps are resolved, and describe the method: fixed scope with stages, or an agile process where the client prioritises a backlog and pays for sprints, in which case the agreement should say that the deliverable is the sprint work rather than a finished product. The client's dependencies (content, access, decisions, third-party systems) should be listed, with the consequence that delay on the client's side moves the timetable and may add cost.

Acceptance and change control

The agreement should set an acceptance process for each stage or deliverable: the tests, the period the client has to test, what counts as a material defect, deemed acceptance if the client does not respond or uses the software in production, and the developer's obligation to fix material defects and re-submit. Changes to scope should be agreed in writing through a change control procedure with their effect on price and timetable, because scope creep without a mechanism is unpaid work.

Payment by milestone or stage

Payment should be tied to events the developer controls or that are deemed to occur: a deposit on signing, stage payments on delivery or deemed acceptance of each stage, and the balance on delivery rather than on launch, with interest and compensation on late payment under the Late Payment of Commercial Debts (Interest) Act 1998 and the developer's right to suspend work for non-payment. For agile work, invoicing per sprint or per month in arrears with a stated notice period for ending the engagement suits both sides better than a fixed price for an undefined product.

Intellectual property and when it passes

The developer owns what it writes until it assigns it, under section 11 of the Copyright, Designs and Patents Act 1988, and the agreement should assign the IP in the bespoke deliverables to the client on payment in full, in writing as section 90 requires, while the developer retains its pre-existing materials, tools, libraries and know-how and licenses them to the client for use with the deliverables; the client's content and data remain the client's. Moral rights should be waived, and the developer should be free to use general skills and techniques on other projects.

Third-party and open source components

The agreement should say that the deliverables may include third-party and open source components, that those components are licensed under their own terms which the client accepts, that the developer will identify components under copyleft licences whose terms could affect the client's use or distribution of the software, and that the developer's IP warranty and indemnity exclude those components and anything the client supplied. Hosting, domains and third-party services procured for the client should be in the client's name.

Warranties, defects, liability, termination and non-solicitation

The developer should warrant that it will perform with reasonable care and skill under section 13 of the Supply of Goods and Services Act 1982 and that the deliverables will materially conform to the specification for a stated warranty period, with correction of notified defects as the remedy and exclusions for the client's modifications and environment; liability should be capped at the fees paid under the agreement with consequential loss excluded, tested under section 11 of the Unfair Contract Terms Act 1977. The client should not solicit the developer's staff for a stated period, either party may terminate for breach or insolvency, and on termination the client pays for work done and receives the deliverables paid for, with IP in unpaid work remaining the developer's.

What it costs

SaaS or technology contract, £995. One contract drafted for how your product or service is sold, delivered and supported. Five working days.

Buying online forms the engagement on payment. The scope is what the saas and technology contracts page describes, you accept the Terms of Service at checkout, and I email you within four working hours to get started. If you would rather ask something first, email me.

What you get

  • A bespoke contract drafted for how your product is sold, delivered and supported
  • Service levels you can meet, with remedies that are proportionate rather than aspirational
  • A liability position that is defensible and will survive enterprise procurement
  • IP and data provisions that fit together rather than contradicting each other
  • A commercial note on where you will get pushback and what is worth conceding
  • One round of amendments

What is not included

  • Negotiating individual enterprise deals, which I quote separately
  • Advice on the law of jurisdictions outside England and Wales
  • Technical security certification or audit
  • Regulatory advice for regulated sectors such as financial services or health

Questions I am often asked

The client keeps adding features and refuses to pay more. What does the agreement do?

It defines the scope and requires changes to go through change control with their effect on price and time. Work outside the scope without an agreed change is chargeable at the stated rates, and the developer may decline it.

When does the client own the code?

On payment in full, when the assignment takes effect. Until then the developer owns it and the client has a licence to test. That is the developer's security for payment.

Can the client stop us reusing code we wrote for them?

For the bespoke deliverables assigned to the client, yes, but the developer retains its pre-existing materials, tools and libraries and may reuse general techniques. The agreement draws that line before the project rather than after it.


✉️
Not sure which service fits, or want to ask something first? Email me a few lines about your business and what you need. I reply, usually the same working day.

This page is general guidance for businesses in England and Wales, not advice on your own circumstances. Last reviewed: September 2026. Email geoffrey@caesar.co.uk.