The eight clauses that matter
Specification + scope
A clear description of what is being built — features, behaviours, performance requirements, non-functional requirements. Ambiguity here is the root cause of most disputes.
IP assignment (s 22(3))
Written, signed assignment from the developer to the customer covering all work product. Without an assignment, ownership turns on who controlled the making — usually the developer in an arms-length build, but potentially the customer where it directed the work (Haupt). Because control is fact-specific, a written section 22(3) assignment is the only reliable route.
Acceptance testing + criteria
How the customer will determine whether the software meets the specification, and what happens if it does not. Time-bound, objective, and tied to defined remedies.
Warranties
Conformance to specification, non-infringement of third-party IP (including open source), no-malware warranty, defect-correction for a defined period after acceptance.
Limitation of liability + indemnities
Caps on direct and indirect damages, IP-infringement indemnity, breach-of-warranty indemnity. Typically capped at fees paid in the preceding 12 months.
Source-code escrow
For mission-critical or proprietary platforms, a tripartite escrow with release triggers (developer insolvency, abandonment, material breach).
Change control
A documented procedure for changes to scope, timeline or fees. Critical for agile and milestone-based engagements where scope evolves.
Term + termination
Term-for-convenience, term-for-cause, termination assistance, and what happens to the deliverables and IP on termination.
Pricing models — fixed, T&M, capped, milestone
The pricing structure of the agreement materially shapes risk allocation. Pick the wrong one and the contract spends 18 months in friction over change orders.
Fixed price
When to use: Well-specified projects with stable requirements. Developer absorbs scope-and-complexity risk.
Watch out for: Heavy upfront specification work; change orders friction; tendency to under-deliver if margins erode.
Time & materials (T&M)
When to use: Agile, iterative builds where requirements evolve. Customer absorbs the risk.
Watch out for: Open-ended cost; weaker accountability; needs strong project governance to avoid budget creep.
Capped T&M
When to use: Most modern enterprise software builds. Combines flexibility with budget certainty.
Watch out for: Cap negotiation can replicate fixed-price friction; works best with milestone-based releases of the cap.
Milestone + outcomes
When to use: Phased deliverables with defined acceptance criteria for each phase.
Watch out for: Milestone definitions must be objective; subjective milestones produce subjective disputes.
Common mistakes founders make
- ⚠Treating the developer’s standard MSA as a fait accompli. Most off-the-shelf SaaS-vendor MSAs are written for the vendor, not the customer. Push back on liability caps, IP terms, and acceptance criteria.
- ⚠Skipping acceptance testing. A build with no acceptance criteria has no objective measure of done — disputes become subjective evidentiary battles.
- ⚠Assuming work-made-for-hire applies. It does not under SA law. Section 22(3) of the Copyright Act requires a written, signed assignment.
- ⚠Forgetting about open-source contamination. A development agreement should require disclosure of all OSS used and warranties that the customer’s use of the deliverable does not breach any OSS licence.
- ⚠Ignoring data-processing terms. If the developer touches personal information at any point (testing with prod data, support access), POPIA s 21 requires an operator agreement.
Frequently asked
When do I need a software development agreement versus a contractor agreement?
A short-form contractor agreement suits a single piece of well-defined work — a feature, a small site, a one-off integration. A full software development agreement is needed when the build is material in scope (months of work), involves multiple deliverables, requires acceptance testing, has SLA implications, or involves a meaningful IP transfer. Anything north of approximately R200,000 of development spend typically warrants a full agreement.
Should the IP vest in the customer on payment, or on acceptance?
Best practice is to vest the IP in the customer on payment of the relevant invoice (or milestone), with a corresponding security interest if payment is staged. Vesting on "acceptance" leaves the customer exposed if there is a dispute about whether acceptance has occurred. Vesting "on signing" leaves the developer exposed if the customer does not pay. Payment-based vesting balances both risks.
What is the right warranty period for custom software?
A defect-correction warranty of 6 to 12 months from acceptance is typical for substantial builds. Bug-fix obligations during this period should be at the developer's cost. After the warranty period, support becomes a separately-contracted service. Warranties of fitness for purpose and conformance to specification should survive indefinitely subject to the limitation-of-liability cap.
Does South African law require source-code escrow?
No statute requires it, but escrow is commercially essential for mission-critical platforms, enterprise SaaS deployments, regulated industries, and any build where the customer's business depends on the platform but does not own the source code. The escrow agent is typically an attorney or specialist escrow company. Release triggers must be carefully drafted — too liberal and the developer is exposed; too narrow and the escrow provides no real protection.
Can I use a US software development agreement template under South African law?
Risky. US templates often: (i) miss the section 22(3) Copyright Act written-assignment requirement; (ii) reference foreign-law concepts (work-made-for-hire) that have no direct SA equivalent; (iii) leave POPIA-required data processing terms out entirely; (iv) impose governing-law and forum clauses that are commercially inappropriate. A SA-drafted agreement is almost always cheaper and faster than negotiating amendments to a US template.
How does an agile build affect the contract structure?
Agile builds typically use a thin master agreement plus iterative statements of work or release schedules. The master covers IP, confidentiality, warranties, liability, dispute resolution. Each sprint or release adds a schedule with scope, timeline and fees. Acceptance criteria are tied to release-level deliverables, not the build as a whole. Change control is built in by design rather than bolted on.
What governing law should I choose for a SA development engagement?
For a SA-to-SA engagement (developer and customer both SA), South African law and the High Court of South Africa. For a SA-customer-to-foreign-developer engagement, push for South African law if the customer's business is materially exposed; failing that, negotiate neutral arbitration (AFSA in SA, or ICC) over foreign-court jurisdiction. Governing law should always match the dispute-resolution forum to avoid procedural friction.