7 clauses every software development contract needs

When a project turns into a dispute, everyone opens the contract. And that is usually the moment it becomes clear the relevant clause is not there.

A software contract is not a complicated document. But there are seven clauses without which every negotiation ends at "we understood it differently".

Here they are, with what each protects and what happens when it is missing.

1. Scope as a written annex

If the contract says "software development", it says nothing. The scope must be a separate annex, and the contract must state that the annex forms an integral part of it.

What goes in the annex: the list of modules, the screens, integrations by name, user roles, and what is explicitly out of scope.

Without it: every new requirement becomes an argument about whether it was included. This is the single largest cause of overruns.

2. The change process

Even with a scope agreed at the start, circumstances change. What matters is how a change is formalised.

Three things belong in this clause: changes are requested in writing, the vendor quotes them within a defined number of days, and work begins only after you approve.

Without it: verbal requests accumulate. At the end the vendor says "that was not in scope" and you say "I asked for it". Both of you are right.

3. Acceptance criteria

The most commonly skipped clause and the most damaging omission.

It should state how the vendor notifies you that work is delivered, how many days you have to respond, and what happens if you do not respond within that window.

A workable formula: the client accepts the work within five working days or submits a reasoned written objection. If no response arrives in that period, the work is deemed accepted.

Without it: the project sits for months in review. The vendor is not paid and you are not using the system. Both sides lose.

4. Code and data ownership

One sentence, but without it you are locked in.

It should state: on full payment, the source code, documentation and database transfer to the client.

Two nuances. First, the vendor's own pre-existing libraries and internal components usually remain theirs, with a perpetual, free licence granted to you. That is normal practice. Second, the database should be yours from the outset, regardless of payment.

Without it: you cannot change vendors. Every small change sends you back to the same door, at whatever price is quoted there.

5. Warranty period

Both the period and its boundary need to be explicit.

What the warranty covers: behaviour that does not match the agreed scope, meaning technical defects. What it does not cover: new feature requests, failures caused by changes you or third parties made, and outages in third-party services.

Workable periods: one month on a small project, two on a mid-size one, three on an enterprise system.

Without it: every defect becomes a negotiation about whether it is warranty work or new work.

6. Limitation of liability

This clause protects the vendor, which is why many clients resist it. But you need it too.

The standard formula: the vendor's liability is limited to the amount actually paid under the contract. Indirect damages and lost profit are excluded.

Why it matters to you: no sound team accepts unlimited liability. Those who do either price it in or simply do not read it — and neither outcome helps you.

Focus instead on the penalty clause: 0.1% of contract value for each day of delay, capped at 10% in total. That is a mechanism that actually works.

7. Termination

Nobody enjoys thinking about this, but the clause is necessary.

It should state how much notice each party gives, how completed work is valued on termination, how the advance is settled, and whether the completed part is handed over to you.

Without it: separation goes to court. Both sides lose time and money, and the system sits half-finished.

The seven clauses at a glance

Client obligations — the eighth clause

This one is requested by the vendor, and it is fair.

Half of all delays originate on the client side: data is not supplied, decisions are not made, nobody attends the demo. So the contract should also set out your obligations: a responsible person is appointed, responses are given within a set number of days, and specified data is provided by specified dates.

If those are not met, the timeline shifts accordingly and it is not treated as the vendor's fault.

The clause looks like it works against you, but in practice it speeds the project up, because it forces internal accountability.

Before you sign

• The scope is a separate annex and named as an integral part of the contract
• The change process is defined: written request, quotation period, approval
• Acceptance criteria and a response window exist
• Transfer of code and database ownership after payment is written in
• The warranty period and its boundary are defined
• A penalty mechanism applies to both parties
• Termination terms and settlement method are present
• Your own obligations are written in as well

Six of eight means the contract works. Fewer than four means do not sign it.

Do you need a lawyer

Yes, but once.

Good practice looks like this: a template is drawn up with a lawyer once and then used for years. Only the scope annex and the amount change from project to project.

Nothing in this article is legal advice — these are simply the places where disputes arise most often in practice. A lawyer aligns them with the law that applies to you.

In summary

A contract is not a sign of distrust. It records what each side expects, and that is precisely what prevents disputes.

Practical steps:

1. Keep the seven clauses as a checklist and run every contract through it
2. Never sign without a scope annex — this is the largest single mistake
3. Insist on acceptance criteria; they are frequently absent
4. Close the code ownership question with one sentence
5. Build a template with a lawyer once, then reuse it