Software Development Contract: Clauses to Check

The short answer

A good software development contract answers seven questions: what is being built, how you pay, how results are accepted, who owns the code, what happens with bugs after delivery, who is liable for what, and how to part ways. If the contract fails to answer even one of them, a dispute is almost inevitable. Before signing, have it reviewed by a lawyer familiar with your country's law: this article is a checklist, not legal advice.

1. Scope of work

The main source of conflict is a different understanding of what the project includes.

Check:

• whether a specification is attached to the contract as an appendix;
• whether user scenarios, platforms, interface languages and integrations are described;
• what is out of scope: content, design, hosting, post-launch support;
• how change requests are handled — through an addendum with a new time and cost estimate.

2. Milestones and payment

Paying everything upfront and paying everything at the end are equally risky. A better option is milestone payments tied to specific deliverables.

• Each milestone has a clear result: prototype, design, backend, release.
• Milestone deadlines are stated, along with what happens when either party causes a delay.
• The pricing model is defined: fixed price or Time & Material with timesheet reports.
• Currency, taxes and invoicing procedure are specified.

3. Acceptance

Without an acceptance procedure, a milestone can be neither closed nor disputed.

• Acceptance criteria: which scenarios must work and on which devices.
• Review period for the client and the format for feedback.
• What counts as a defect and what counts as a new requirement.
• What happens if the client stays silent: contracts often state that a milestone is deemed accepted once the review period expires.

4. Intellectual property

Clients check this clause least often, yet its consequences are the most serious.

• Whether exclusive rights to the code, design and documentation pass to the client, and when — usually upon payment.
• Whether the source code is delivered, not just a working program.
• Which third-party libraries and open-source components are used and under which licenses.
• Whether the contractor can reuse their own pre-existing tools (frameworks, modules), and on what terms they are licensed to the client.
• Whether the contractor may mention the project in their portfolio.

5. Warranty

• The warranty period during which bugs are fixed free of charge.
• What the warranty covers: defects in delivered features, but not new requirements or issues caused by third-party changes.
• Response time for critical bugs.
• How the warranty differs from paid support after it ends.

6. Liability and confidentiality

• Limitation of liability: the maximum amount the parties are liable for to each other.
• Penalties for delays — for both the contractor and the client (for example, late payment or late materials).
• NDA: what information is confidential and how long the obligation lasts.
• Handling of personal data if the system processes customer data.

7. Termination

• Grounds for termination for each party and the notice period.
• Payment for work already completed.
• Handover of everything built upon termination: code, access, documentation.
• Dispute resolution: negotiation first, then court or arbitration in a specific jurisdiction.

Quick checklist before signing