In most respects, a contract for software development is the same as any other services contract.  There are however, certain issues specific to software development that should be covered.

Changes to the Scope of Deliverables

Software development projects are particularly susceptible to “changes of scope” mid-stream.  Development clients will often change requirements as the concept for an application evolves.  Developers should include mechanisms in their contracts that:

  • define what a “change of scope” is; and
  • handle changes to the scope.

It’s hard to avoid relying on adjectives like “minor” or “major” when describing what constitutes a “change of scope”.  The nature of the project will ultimately dictate what language is best suited to the situation.

It’s a good idea to agree on how changes of scope will be priced before they happen.  A common method is to include an hourly rate in the contract such that if there is a change, any extra work done by the developer as a result will be charged at the hourly rate.

Testing and Acceptance

Every software project has bugs, but sometimes it takes a while for them to be discovered.  Most developers build a “testing and acceptance” period into a contract for development services so it’s clear that they’re not responsible for minor bugs discovered months after they have provided the deliverables.

A typical period for testing is 10 business days after the developer provides the deliverables.  In other words, after 10 business days of testing, the client will be “deemed to have accepted” the product, and any bugs that appear after that will not be the responsibility of the developer.  This kind of obligation has the effect of making sure that the client concentrates on finding and notifying a developer of bugs within a reasonable time period.

Intellectual Property

A Development Agreement needs to have clear provisions about what intellectual property is transferred to the client by the developer.  Most developers license their “background intellectual property” as opposed to assigning ownership.  Background IP is usually defined as slabs of code for certain kinds of functionality that a developer re-uses for multiple clients.  If a developer doesn’t take this precaution, they will be in a position where they have assigned intellectual property to a client, and by using it with subsequent clients, they will be infringing on the intellectual property of their previous client.

Back to Technology