What a development agreement is
A software development agreement is a services contract: the customer pays the developer to build software according to an agreed specification. It is distinct from a software licence (which transfers a pre-existing right to use existing software) and from a SaaS subscription (which grants ongoing access to hosted software the vendor retains). The deliverable of a development agreement is — usually — a piece of custom software the customer owns or exclusively licenses, plus the source code and documentation necessary to operate and maintain it.
Under South African law, the agreement sits at the intersection of contract law and copyright law. Contract law governs the commercial relationship — scope, fees, timelines, performance, dispute resolution. The Copyright Act 98 of 1978 governs ownership of the resulting software. The two are coupled: a development agreement that does not deal explicitly with IP ownership leaves the customer with the contract performance they paid for but not, under the default rule, the IP they assumed they bought. This is one of the most consistent — and consistently expensive — drafting failures in SA tech.
Beyond contract and copyright, three more statutes shape modern development agreements: POPIA where the developer accesses personal information (testing with production data, support access, training); ECTA for electronic formation and signature; and the Cybercrimes Act for offences the deliverable must not facilitate (data interference, unauthorised access, malware). For consumer-facing development (a SaaS startup’s build of its core product, where the customer is also the eventual consumer-facing operator), CPA awareness is needed downstream even though the development agreement itself is B2B.
Standalone vs MSA + SOW structure
Two structures dominate. Standalone development agreement: a single document covering everything, signed once for a single project. MSA + SOW: a Master Service Agreement that captures standing terms (IP, liability, warranties, confidentiality, dispute resolution) once, with project-specific terms (scope, fees, timeline) captured in subsequent Statements of Work issued under the MSA.
Standalone is appropriate for one-off engagements. MSA + SOW is appropriate where the relationship will likely involve multiple projects — typical for development firms with recurring customers and for in-house development teams that contract regularly with multiple suppliers. The MSA structure produces cleaner negotiations over time (the standing terms are settled once) at the cost of higher upfront drafting investment. See our MSA guide for the structural detail.
1. Specification + scope
The specification is the document that says what is being built. It is the single most important factual element of a development agreement, because almost every dispute about whether the developer has performed turns on the specification. Three approaches: (i) a waterfall-style detailed specification settled before signature (every screen, every feature, every behaviour documented); (ii) an agile-style functional outline with the detail filled in iteratively (typical user stories, acceptance criteria added per sprint); (iii) a hybrid where high-level scope is fixed but detail evolves.
Whichever approach is used, the agreement must capture: the functional requirements (what the software does); the non-functional requirements (performance, scalability, security, accessibility); the technical environment (platforms, third-party integrations, data formats); and the explicit exclusions (what is not in scope). Ambiguity here is the root cause of most subsequent disputes — when the customer expects feature X and the developer thinks it is out of scope, who is right turns on the specification, not on what either party thought.
For agile engagements, the agreement should specifically authorise the iterative development of the specification through user stories or backlog items, with each sprint or release having its own acceptance criteria. The mistake is signing an agile build under a fixed-scope contract with no change-control mechanism — the contract assumes stability that the development methodology assumes will not exist.
2. IP ownership + assignment
Software is protected as a literary work under section 2(1)(i) of the Copyright Act 98 of 1978. Copyright vests automatically in the author — the natural person who wrote the work. Section 21(1)(b) carves out an employment exception: where the work is made by an employee in the course of their employment under a contract of service, copyright vests in the employer. Independent contractors are not employees; section 21 does not deem the commissioning party the owner of work done by a contractor. Default position for a development engagement with a contractor or development firm: copyright remains with the contractor unless validly assigned.
Section 22(3) sets the requirements for valid assignment: the assignment must be in writing and signed by or on behalf of the assignor. Verbal handshakes, oral side-agreements, and informal email understandings do not satisfy section 22(3). A development agreement that promises the customer "will own the IP" without containing a properly-drafted assignment clause is, in copyright terms, ineffective — the customer may have a contractual claim against the developer but does not own the copyright.
Best practice for the assignment clause: (i) describe the work being assigned (the deliverables of the agreement); (ii) include "all intellectual property rights" rather than just copyright (covering trademarks, design rights, database rights, patents where applicable); (iii) make the assignment effective on payment of the relevant invoice or milestone (so the developer retains IP until paid); (iv) include a moral-rights waiver under section 20 of the Copyright Act; (v) include a further-assurance clause obliging the developer to execute additional documents to perfect the assignment in foreign jurisdictions if needed; (vi) address pre-existing IP and any necessary licence-back from the customer for the developer\'s use of pre-existing tools.
Open-source contamination must be addressed in parallel. The assignment of "all IP in the deliverables" is meaningless if the deliverables embed GPL-licensed components that require the customer to release its derivative work under GPL. The agreement should require disclosure of all OSS components used, warranties that no copyleft-licensed components have been incorporated without express consent, and indemnification against OSS-related third-party claims.
3. Acceptance testing + remedies
Acceptance testing is the procedural mechanism by which the customer confirms the deliverable meets the specification. A robust acceptance regime: developer delivers; customer has a defined testing period (typically 10–20 business days) to test against agreed acceptance criteria; customer issues one of three responses — accept, reject with specified defects, or conditionally accept with a defect list for remedy.
The acceptance criteria must be defined in advance — typically in the specification or a separate acceptance-criteria schedule. Vague criteria ("the deliverable will be acceptable in form and substance to the customer") favour the customer and produce disputes; over-specific criteria favour the developer and produce gaming. A defensible middle ground: criteria tied to verifiable functional and non-functional requirements with quantitative targets where possible (page-load times, throughput, accuracy rates), and a defect-classification scheme distinguishing critical, major, and minor defects.
Remedies for rejection should be calibrated to defect severity. For critical or major defects: developer obligation to remedy within a defined cure period (typically 10 business days), with the testing cycle restarting on remediation. For minor defects: conditional acceptance with a list of items for the developer to address in a defined follow-up period, allowing the project to progress. For chronic failure (repeated rejection of the same deliverable across multiple cycles): the customer\'s right to terminate with refund of payments made for the unaccepted work, or to engage a third party to complete the work at the developer\'s cost.
Deemed acceptance — where failure to issue an acceptance or rejection within the testing period is treated as acceptance — is standard but should be balanced. Customers should ensure their internal acceptance procedures will reliably issue formal responses within the window; developers should not rely on deemed acceptance as a substitute for genuine customer sign-off where the customer is paying material amounts.
4. Warranties + indemnities
Standard developer warranties: (i) ownership and right to assign all delivered IP; (ii) non-infringement of third-party IP, including OSS; (iii) substantial conformance to the agreed specification; (iv) defect-correction for a defined period after acceptance (typically 6 to 12 months); (v) no-malware (no time-limited code, back-doors, hidden functionality); (vi) authority to enter the agreement; (vii) maintenance of professional skills and care in performance. Disclaimers exclude implied warranties of merchantability and fitness for purpose under the common law.
Indemnification typically attaches to the IP-infringement warranty. Standard structure: the developer indemnifies the customer against third-party claims that the deliverable infringes third-party IP; the indemnity covers legal costs, damages, and settlement amounts; the customer must give prompt notice, allow the developer to control the defence, and reasonably cooperate. Indemnification may be capped (at a multiple of fees paid, or at a higher cap than ordinary liability) or uncapped — uncapped IP indemnification is unusual but increasingly demanded by enterprise customers.
Where personal information is involved, additional warranties should cover: compliance with POPIA section 19 security measures; no use of customer-supplied test data for any other purpose; return or destruction of customer data on completion. Where the deliverable will process personal information in production, the developer should warrant that the deliverable is capable of supporting the customer\'s POPIA compliance — though responsibility for the customer\'s operational compliance remains with the customer.
5. Pricing models + payment
Four pricing models dominate. Fixed-price: agreed total fee for an agreed scope; developer absorbs scope-and-complexity risk; suits well-specified projects with stable requirements. Time and materials (T&M): customer pays hourly rates for actual time worked; customer absorbs all risk; suits agile, iterative builds. Capped T&M: T&M with a maximum spend ceiling; combines budget certainty with flexibility. Milestone-based: payments tied to defined deliverables; aligns commercial incentives with progress.
Most modern enterprise builds use capped T&M with milestone releases of the cap: the customer caps total spend; the cap is released in tranches tied to milestones; T&M billing applies within each tranche. This balances developer cash flow against customer budget certainty.
Payment terms should specify: invoice frequency (monthly for T&M, milestone-based for fixed-price); payment terms (net-30 is standard, net-15 for tight relationships, net-60 for large enterprise customers); late-payment interest (commonly prime plus 2%); customer\'s right to dispute charges within a defined period; developer\'s right to suspend work for non-payment after notice. Currency: Rand for SA-domestic work; USD/EUR/GBP for cross-border. Exchange-rate clauses should address who bears exchange-rate risk between invoice and payment.
6. Change control
Change control is the procedural mechanism for handling scope changes during execution. Even the best-specified projects encounter changes — clarifications, expansions, course corrections in response to early findings. The agreement must provide a structured way to handle them.
A defensible change-control regime: any change must be documented in a written change order; the change order specifies the scope adjustment, schedule impact, and fee impact; both parties sign the change order before the change is implemented. Standard practice: minor changes within a defined threshold (commonly 5% of contract value, or below a fixed Rand amount) can be absorbed without formal change orders; significant changes require formal approval; the customer cannot be deemed to have agreed to a change by mere acquiescence or use of the modified deliverable.
For agile builds, change control operates at the backlog level: the agreement permits the parties to add or modify backlog items within an existing sprint cadence, with cost impacts captured per sprint rather than per change. The change-control mechanism still applies, but at sprint boundaries rather than individual feature boundaries.
7. Source-code escrow
Source-code escrow is the tripartite arrangement under which the developer lodges source code with an independent escrow agent, to be released to the customer on defined triggers — developer insolvency, abandonment of the product, material unremedied breach. Escrow is essential for mission-critical platforms where the customer\'s business depends on the software but does not own or operate the source code directly.
For full detail of the structure, deposit materials, verification, and release-licence terms, see our dedicated source-code escrow guide. The development agreement should reference the escrow arrangement and obligate the developer to maintain ongoing deposits as part of the development engagement.
8. Term + termination + exit
Termination rights typically include: termination for material unremedied breach (with a defined cure period); termination for insolvency or change of control; termination for force majeure beyond a defined duration; and termination for convenience (typically a customer-only right with notice and payment for work completed). The treatment of work-in-progress on termination is critical — does the customer get the deliverables completed so far, the IP in them, the source code? Default: customer pays for work completed and receives ownership of completed deliverables on payment.
Post-termination obligations should cover: return or destruction of customer materials; transition assistance to a successor developer (typically defined hours of cooperation at agreed rates); documentation handover; survival of warranties, indemnities, and confidentiality. For escrow-protected builds, post-termination triggers should be explicitly tied to escrow-release triggers so the customer can access source code if termination occurs in adverse circumstances.
Agile vs waterfall structures
Traditional waterfall: detailed upfront specification, fixed price, sequential phases (analyse → design → build → test → deploy), defined acceptance at the end. Suits well-understood domains with stable requirements. Modern agile: high-level outline, iterative development in sprints, evolving backlog, acceptance per sprint or release. Suits domains with uncertain requirements, customer-driven discovery, or fast-moving markets.
The contractual implications differ: waterfall fits naturally into fixed-price contracts; agile fits naturally into capped T&M with sprint-based release. Mismatches produce friction: an agile build under a fixed-scope contract produces change-order disputes; a waterfall build under T&M produces unbounded billing. Modern SA practice gravitates to "agile fixed-price" structures — fixed cap, agile execution, change-control mechanism for scope shifts beyond expected sprint capacity.
Cross-border development
SA customers engaging foreign development firms — typically in India, Eastern Europe, or the US — face additional considerations: governing law and forum (push for SA law; failing that, neutral arbitration over foreign-court jurisdiction); withholding tax under section 35 of the Income Tax Act 58 of 1962 on payments to foreign service providers; section 72 POPIA cross-border transfer where the developer accesses SA personal information for testing or support; exchange-control compliance for material foreign payments; and intellectual-property territorial rights, which require IP assignment to be effective in multiple jurisdictions, not just SA.
SA developers selling to foreign customers face inverse considerations: foreign-law governing-law clauses (resist where possible); foreign-court jurisdiction (resist; prefer arbitration); foreign currency contracting and exchange-rate management; and IP assignment effective in the customer\'s home jurisdiction — typically requiring local-counsel review of the assignment language and additional formality where the customer\'s home jurisdiction has stricter requirements than SA.
Common SA pitfalls
Assuming work-made-for-hire applies under SA law
It doesn’t. The US "work made for hire" doctrine has no direct SA equivalent. Section 21 of the Copyright Act vests copyright in employers for employee-created work in the course of employment, but does not deem commissioning parties the owners of contractor-created work. Without a written, signed assignment under section 22(3), the contractor remains the owner.
Skipping the acceptance regime
A build with no defined acceptance criteria has no objective measure of done. Disputes become evidentiary battles about what was promised, what was delivered, and whether the gap matters. A specific, criteria-based acceptance regime costs little to draft and prevents most subsequent disputes.
Ignoring open-source contamination risk
A development agreement that doesn\'t require OSS disclosure and warranties leaves the customer exposed to discovering, post-acquisition or pre-investment, that GPL-licensed components have contaminated the proprietary code. The remediation cost — replacing components, restructuring code — often dwarfs the original development cost.
No change-control mechanism in agile builds
Signing an agile build under a fixed-price contract with no change-control creates predictable disputes. Either the developer absorbs scope evolution at margin cost, or the customer faces unexpected change orders. The change-control mechanism resolves this in advance.
Forgetting the POPIA operator agreement
If the developer touches personal information during the engagement — typical for support, testing with production data, or any data-handling functionality — section 21 POPIA requires an operator agreement. Often embedded as a schedule to the development agreement, sometimes overlooked entirely.
No exit plan
When the engagement ends — successfully or otherwise — what happens to in-flight work, documentation, source code, and the developer\'s residual obligations? Without a defined exit framework, terminations become protracted commercial disputes about who owes what to whom.
Frequently asked
What is the difference between a software development agreement and a SaaS subscription?
A software development agreement is a services contract — the customer pays the developer to build something. A SaaS subscription is a service-access contract — the customer pays for ongoing access to software the vendor owns and hosts. The development agreement produces a deliverable that the customer owns (or licenses); the SaaS subscription does not transfer ownership. Different legal frameworks apply: development agreements turn heavily on specification, acceptance, and IP assignment under the Copyright Act 98 of 1978; SaaS subscriptions turn on access rights, service levels, and POPIA operator obligations.
Who owns the source code at the end of a custom development engagement?
It depends entirely on what the contract says. Under section 21 of the Copyright Act 98 of 1978, where software is created by an employee in the course of employment, the employer owns it. Where it is created by an independent contractor (the typical development-firm scenario), copyright vests in the contractor unless validly assigned in writing under section 22(3). Most well-drafted SA development agreements provide for assignment to the customer on payment of the relevant invoice or milestone; without that clause, the customer ends up with at best an implied licence.
When should development IP vest in the customer — on signing, on payment, or on acceptance?
Payment-based vesting is the cleanest balance of risk. Vesting on signing leaves the developer exposed if the customer does not pay. Vesting on acceptance leaves the customer exposed if there is a dispute about whether acceptance occurred. Vesting per-milestone or per-invoice — IP in deliverables vests in the customer when the corresponding invoice is paid — protects both parties and aligns commercial incentives.
How does acceptance testing work in a SA development agreement?
A standard acceptance regime: developer delivers the build (or milestone deliverable); customer has a defined period (10–20 business days) to test against agreed acceptance criteria; customer issues acceptance, rejection with specified defects, or conditional acceptance with a list of items to be remedied. The agreement should specify: what counts as a defect (typically deviation from specification, not absence of features not specified); the developer's obligation to remedy defects within a defined cure period; the consequences of repeated rejection (typically the customer's right to terminate with a refund of unaccepted work).
What is the difference between a fixed-price, T&M, and capped T&M development engagement?
Fixed-price: pre-agreed total fee for an agreed scope. Developer bears scope-and-complexity risk; customer bears commercial-need risk. Suits well-specified projects. T&M (time-and-materials): customer pays for actual time at agreed hourly rates. Developer bears no scope risk; customer bears all risk. Suits agile, iterative builds. Capped T&M: T&M with a maximum spend cap. Customer caps exposure while preserving flexibility; developer manages within the cap. Most modern enterprise builds use capped T&M with milestone-based release of the cap.
Are agile and fixed-price compatible in a SA development agreement?
Tension. Agile assumes evolving requirements; fixed-price assumes stable requirements. Hybrids work: a fixed-price master with iterative SOWs (each SOW is fixed but small); or a capped T&M structure with agile execution; or "agile fixed-price" with a fixed budget but flexible feature mix. The structure that fails: a single fixed-price contract for an agile build with no change-control mechanism — produces predictable disputes when the scope evolves and no one knows whether the changes are billable.
How does source-code escrow work in a development engagement?
A tripartite arrangement — developer, customer, escrow agent — under which the developer lodges source code with an independent agent who releases it to the customer on defined triggers (developer insolvency, abandonment, material breach). Escrow is commercially essential for mission-critical platforms but adds complexity and cost (R8,000+ for the escrow agreement, R3,000–R8,000 setup with the agent, R3,000–R6,000 annual maintenance). See our <a href="/software-technology-law/source-code-escrow-agreement">source-code escrow guide</a> for the detailed structure.
What warranties should a SA development agreement contain?
Minimum: (i) warranty of ownership and right to assign all delivered IP; (ii) non-infringement warranty (including open-source compliance); (iii) substantial conformance to the agreed specification; (iv) defect-correction warranty for 6–12 months post-acceptance; (v) no-malware warranty (no time-limited code, back-doors, or hidden functionality); (vi) authority warranty (the developer has the right to enter the agreement). Indemnities should track the warranties.
How should liability be limited in a development agreement?
B2B SA practice: cap of 12 months of fees paid (or 100% of the contract value, whichever is greater) for direct damages. Standard carve-outs: IP infringement indemnification (often uncapped or capped at higher amount), confidentiality breach, gross negligence, wilful misconduct, fraud, and (increasingly) POPIA penalties. Indirect, consequential, and special damages excluded — loss of profits, loss of business opportunity, reputational harm.
What does cross-border development look like?
When a SA customer engages a foreign development firm (or vice versa), additional considerations apply: governing law and jurisdiction (push for SA law; failing that, neutral arbitration over foreign-court forums); section 35 Income Tax Act withholding (payments to foreign service providers may attract WHT); section 72 POPIA cross-border transfer (where the developer accesses SA personal information); exchange-control considerations under the Reserve Bank framework for material foreign payments; intellectual-property territorial rights (assignment of IP rights in multiple jurisdictions, not just SA).
Need a development agreement drafted or reviewed?
Standalone development agreements from R12,000. Master + SOW frameworks R20,000–R30,000. 24-hour review of an existing draft from R7,500.