Software development SOWs: Protecting your IP and deliverables

Defining technical scope is difficult because it requires translating business requirements into technical specifications — a process that rarely produces a document both parties interpret the same way. The solution is not to write a longer specification, but to write a clearer one.

A practical approach is to define scope in terms of features and acceptance criteria rather than technical implementation. 'User authentication system allowing login with email and password, with password reset functionality via email, tested to work on Chrome, Safari, and Firefox' is clearer than 'implement auth module'. The client knows what they're getting; the developer knows what done looks like.

The specification should also explicitly describe what is not in scope — third-party integrations, mobile applications, specific browser versions, accessibility compliance — anything a client might reasonably assume is included but which falls outside the agreed work.

Without an acceptance testing process, a client can refuse to sign off on completed work indefinitely. The SOW should define the acceptance testing period (typically five to ten business days after delivery), the criteria for acceptance, the process for raising defects, and what constitutes a defect versus a change request.

A defect is a failure to meet an agreed acceptance criterion. A change request is a modification or addition to what was agreed. This distinction matters because defects are fixed at the developer's cost within the original scope; change requests generate a new SOW or a variation order with additional fees.

Deemed acceptance — where work is considered accepted if the client does not respond within the testing period — is a critical clause for project momentum. It prevents projects from stalling indefinitely at the delivery stage while a client considers their response.

Software development agreements need to address two categories of IP: background IP and foreground IP. Background IP is the existing code, libraries, frameworks, and tools the developer brings to the engagement — their pre-existing intellectual property. Foreground IP is the new code and software specifically created for the client under the SOW.

In most software development agreements, the client owns the foreground IP (subject to payment) while the developer retains ownership of background IP with a perpetual licence granted to the client to use it as part of the delivered system.

This structure matters for both parties. The developer retains the right to use their frameworks and libraries in other projects. The client owns the custom code built specifically for them. Neither party is disadvantaged, but both need the agreement to reflect this clearly.

A software development SOW should include a warranty period — typically thirty to ninety days after delivery — during which the developer will fix defects in the delivered software at no additional charge. After the warranty period, defect fixing is a support engagement governed by a separate agreement.

Clearly distinguish between warranty obligations (fixing what didn't work as agreed) and support obligations (ongoing maintenance, updates, and improvements). A client who expects free ongoing updates under a warranty clause is misinterpreting the document. A developer who refuses to fix a genuine defect within the warranty period is in breach of contract.

Post-warranty support — if offered — should be documented in a separate maintenance and support agreement that specifies response times, scope of support, and fees.