What a software development contract should include

Five things matter most in a software development contract: what exactly is being built and how it is accepted, how the work and its changes are paid for, who owns the code, what warranty and support follow delivery, and how to terminate with a project handover. Everything else is detail a lawyer adapts to your case.

Below is an overview of the key terms from a business perspective. It is not legal advice: have a lawyer review the final contract.

Which sections should a development contract contain?

A development contract should cover the scope of work, delivery and acceptance, price and payment terms, ownership of the result, warranties, confidentiality and termination. The specification and milestone schedule usually go into appendices so they can be updated without rewriting the contract.

Section	What it fixes	Typical mistake
Scope	What is being built, a reference to the spec or milestone descriptions	"Website development" with no description
Delivery and acceptance	How results are checked, acceptance deadlines, the definition of done	No criteria; acceptance by gut feeling
Price and payment	Pricing model, milestones, how changes are paid for	Full prepayment for the whole project
Ownership	Who owns the code, design and documentation	The vendor keeps rights by default
Warranty and support	Free bug-fixing period, support terms	Warranty not mentioned
Confidentiality	Which data is protected and how	No terms on the client's data
Termination	How to exit, handing over code and access	No handover terms

We compared pricing models — fixed price and time-based billing — in fixed price vs Time & Materials.

Who owns the code?

Code ownership must be stated explicitly in the contract. Default rules vary by jurisdiction: in some countries commissioned software belongs to the client unless agreed otherwise, while in others the developer keeps copyright unless there is a written assignment. Do not rely on defaults: the contract should spell out what transfers to the client and when.

What to include:

• assignment of intellectual property in the code, design and documentation — on payment for each milestone or on creation;
• delivery of the source code with its full history, not just a compiled build;
• a list of third-party libraries and their licences — those rights are not transferred, but the licences must permit your use;
• the vendor's right to reuse its own pre-existing tools and libraries — with a licence for the client;
• showing the project in the vendor's portfolio — only with the client's consent.

Photo: Unsplash

How should delivery and acceptance be described?

Describe delivery and acceptance so both sides understand what counts as done: results are checked against the criteria in the specification, the client has a fixed period to review, and feedback is given as a list. Without this, acceptance turns into an argument and payment becomes hostage to the disagreement.

What to specify:

1. Criteria of done — scenarios and acceptance criteria from the specification.
2. A review period — for example, several business days after the demo.
3. How feedback is given — in writing, as a list, separating defects from new requests.
4. What happens if the client does not respond in time — the result is deemed accepted.
5. How requirement changes are handled — through an amendment with an estimate.

We covered how to describe scenarios and criteria in how to write a software requirements specification.

Which terms protect the client?

The client is protected by milestone payments for accepted results, access and the repository on the client's side, a warranty period and a clear termination procedure with a project handover. These terms do not make the contract hostile to the vendor — good agencies accept them without argument.

Terms worth paying attention to

• payment by milestone rather than upfront for the whole project;
• repository, hosting, domains and third-party services on the client's accounts;
• a warranty period during which bugs are fixed free of charge;
• a termination procedure: notice, payment for work done, handover of code, documentation and access;
• liability for disclosing confidential information and personal data;
• how the vendor replaces key specialists.

If it ever comes to changing vendors, see how to switch development vendors.

Which type of contract should you choose?

The type of contract depends on the working model: a project with a clear result usually uses a fixed-scope development agreement with IP assignment, while long-term team work uses a services agreement with monthly billing. They are often combined: a master services agreement plus statements of work for individual stages.

What to consider:

• project work with a defined result — an agreement with detailed acceptance and IP transfer;
• a dedicated team and support — a services agreement with work reports and IP assignment for what is created;
• a master agreement — convenient with many stages: common terms are fixed once;
• tax and currency issues — if the vendor is in another country.

In short

• The key terms are scope, acceptance, payment, code ownership, warranty and termination.
• State code ownership explicitly, including source code delivery and a list of third-party licences.
• Acceptance follows the specification's criteria, with a fixed deadline and written feedback.
• Milestone payments, client-side access, a warranty period and a handover procedure protect the client.
• Have a lawyer review the final text, especially when working with a vendor in another country.