This is not a substitute for legal advice. It is a list of the places we repeatedly find software contracts left blank — and every blank later becomes an argument in which neither side is clearly wrong.
1. Scope written as verifiable statements
The scope annexe should be a list of things the system does, described from the user’s side: "accounting can produce a receivables report by ageing bucket, filtered by customer group, downloadable to Excel." Any line you cannot verify by clicking through gets rewritten.
Alongside it there should be an out of scope section stating clearly what is NOT included. That section protects both sides and is usually omitted out of awkwardness.
2. Acceptance criteria and response deadlines
Who signs off, against which test scenarios, within how many days? And equally important: what happens if the buyer does not respond within that window?
Without this clause, projects hang indefinitely at final acceptance because the responsible person is busy — and the supplier has no basis on which to close the project.
3. Source code ownership and third-party libraries
State plainly that code written for this project belongs to the buyer once payment is complete. Also state plainly what does not belong to the buyer — open-source libraries, subscription services — and their licences.
Omitting the second half is a reliable source of misunderstanding: the buyer assumes they own everything, including the supplier’s shared platform.
4. Whose data it is and how to get it out
For most businesses this clause matters more than the source code clause. It should state:
- Operational data belongs to the buyer without restriction.
- The buyer may request a full export at any time in a readable standard format — CSV or a database dump — within a stated number of working days.
- After termination, how long the supplier has to delete the data and confirm it in writing.
5. Warranty: how long and what it covers
"Twelve months warranty" is not enough on its own. Three kinds of work must be distinguished and handled separately:
| Kind | Example | Under warranty? |
|---|---|---|
| Defect | Receivables computed wrongly, invoice will not print | Yes, fixed free |
| Change of requirement | Adding a new field to a form | No, quoted separately |
| Usage support | Showing new staff how to do something | By agreement; state the hours included |
Alongside it there should be committed response times by severity: how quickly for a fault blocking all trading, how quickly for a minor one.
6. Support after the warranty
Agree the annual support fee or hourly rate for after the warranty period, in advance. Without it you negotiate from weakness a year later, because by then exactly one firm understands the system.
7. Termination and transition
The clause nobody wants to use but everybody needs: if the relationship ends, what happens? At minimum three points:
- 1Payment for work completed and accepted up to the stopping point.
- 2Handover of source code, documentation and data in their current state, within a stated number of days.
- 3A paid transition period long enough for a new team to take over — usually two to four weeks.
A good termination clause is one that makes both sides comfortable signing, not one that makes one side afraid to leave.
At SealCore the source code, data and handover points are standard contract terms rather than paid options — the full reasoning is in Source code handover.
Want to talk specifics?
SealCore surveys at your premises and sends a fixed quote after the first session — including when the conclusion is that you do not need custom software.
