Go To Index   module 1   module 2   module 3   module 4   module 5   module 6   module 7   module 8   module 9   module 10   module 11   module 12

Sample Page - Foundational Documents

Course 1 Lesson 08 - Learning Outcomes

On completing this module you should be able to:

  • select and contract with a website or mobile app developer more confidently and securely;
  • prepare an overview or clause listing of a required development agreement; and
  • draft contracts adopting language which makes them more legally effective.


First watch the above case study video as Noric the lawyer takes Chris the developer and David the publisher through the new and more comprehensive web and app development agreement. Noric responds to Chris’s queries about the non-exclusivity clause, outlining the restrictions on Chris’s role as developer and on his claim to copyright in the images, audio and electronic content he will be developing. David is also reminded of the risk and benefits of using open sources software as contrasted with proprietary software.

Needs Assessment

Organisations need to properly review their business or organisational needs before they contact developers. A range of review techniques can be used. They include chats with advisers, interviews, brainstorming workshops, surveys, expert review, competitor analysis, statistical analysis and strategic planning. 

Developer Suitability - Short Checklist

Here's a list of questions to ask when assessing the suitability of a developer.

  • Do the developer's competencies match the project?
  • Does the developer have relevant experience, testimonials and references?
  • Is the developer's usual way of working suitable - consider project management, training, outsourcing, and approach to pricing?
  • Is the business of the developer financially sound?
  • Is there solution value for money? 

Overview of a Developer Agreement

Among the templates included in this course are the two below relevant to this module. Some elements common to both are overviewed below.

  • Mobile App Development Agt
  • Website Development Agt [Client Bias]

A good website and mobile app development agreement addresses and answers many questions. When drafted to be biased in favour of a client seeking a development of a website and app, the agreement can include the agreement structure and clause subject matter below.

  1. Parties
  2. Recitals
  3. Interpretation
  4. Duration
  5. Development Obligations
    • Services
    • Completion Date and Liquidated Damages
    • Source Materials Delivery
    • Proofing and Sign-offs
    • Project Management
    • Warranty Period
    • Training
    • Search Engine Optimisation
  6. Hosting
  7. Acceptance Testing
  8. Maintenance
    • Developer Obligations
    • Backups
    • Exclusions
    • Case Logging
    • Case Prioritisation
    • Response Protocol
  9. Fee
  10. Intellectual Property
  11. Warranties
  12. Confidentiality
  13. Termination
  14. Consequences of Termination
  15. Dispute Resolution
  16. General
  • Scope of Work Outline
  • Payments Schedule
  • Acceptance Testing Criteria
  • Hourly Rates 

Why Use Written Contracts?

In simple terms a contract is a legally enforceable agreement formed by what people say to each other, what they do or what they write.

Very few contracts are required to be in writing (exceptions include an assignment or exclusive licence of copyright). However, many misunderstandings and disputes can be avoided by recording an agreement in writing.

For most situations, there are seven legally essential requirements for the formation of a contract.

  1. Intention - An intention to create a legal relationship (eg to make promises legally enforceable).
  2. Offer - A proposal which may be accepted, or otherwise rejected or terminated resulting in no contract.
  3. Acceptance - Acceptance of an offer and its terms and conditions.
  4. Terms - Terms and conditions. These are treated as a separate element because not all offers expressly state or clearly identify all the relevant terms and conditions.
  5. Consideration - Something of value given in exchange for a promise. Consideration is not required if the contract is signed as a deed.
  6. Capacity - The contracting parties have legal capacity (eg they are not bankrupts, minors or subject to mental health law).
  7. No other ground for legal issues or invalidity - Grounds include uncertainty, mistake, fraud, misrepresentation, misleading representation, duress, undue influence, unconscionability, illegality, good faith, penalty, unenforceable restraint of trade, etc. Sometimes these grounds are grouped under the heading "genuine consent".

Note that none of these essential features require a written document or signature. However, a written agreement and evidence of acceptance can save the day when disputes arise. Signature is one way in which acceptance is given.

A written agreement can have greater practical benefits if more is done than just what is legally essential to form a contract. If more is done, a written agreement can additionally address commercial, technical, managerial and practical needs.

To do this, before drafting begins ask "what if' questions. For digital media and copyright assets these questions include:

  • how to regulate customer use of functionality, eg social media and user-generated content;
  • whether customers will be grouped into one or more categories for payment purposes; and
  • setting the legal basis on which service to a customer in breach can be terminated.

When commercial, technical, managerial and practical "what if" questions are answered a business contract can position the value proposition of a business or its products. This can produce a clearer statement of the functionality of a product and its inclusions, its price, and other relevant terms. There are many legal benefits - minimised legal fees; higher commercial valuations founded on legal certainty; and lower chance of misunderstandings leading to disputes or litigation.

It should be clear by now that through customisation and a degree of innovative drafting, a contract can support a wider range of needs. Here are some high-value returns from the type of customisation promoted in this module.


A contract can support knowledge management - by imposing project management methodologies you can insist on record keeping, document retention and document storage requirements and thereby avoid having to constantly monitor performance of these tasks by others.

For performance improvement and risk management - a contract can be like a structural engineer's blueprint recording or highlighting relationships between components and stress zones.

In preparation for disaster recovery - a contract can record valuable background or historical information, especially in its recitals and as attachments, to recover after a relationship breakdown, loss of staff or financial difficulties.

A contract can help exit from a difficult relationship. For this a crafted dispute resolution clause can facilitate separation without a lengthy or costly battle over such issues as who owns what or who gets what.


Contract Language 

To achieve all this, before drafting legal content in a contract, it is useful to have settled decisions about commercial, technical, managerial and practical content. This helps capture requirements in legally effective language.

This language should ideally be:

  • precise;
  • consistent;
  • unambiguous;
  • comprehensive;
  • thoughtful;
  • structured; and
  • reusable. 

Draft Using a Modular Approach

The more structured a contract is, the more useful it is for its users. Structured contracts are best formed by working with pre-settled standardised elements. These include pre-designed contract document layouts, standardised clause heading wording, and a chronological or other logical order of clauses. These are among the requirements for adopting a modular approach for contract drafting.

A modular approach achieves many benefits and is in contrast to fully bespoke drafting.

The modular approach to drafting can be achieved by:

  • at the document component level - adopting standardisation of document layouts and contract clause types, headings and wording;
  • at the document level - focusing all content to achieve its core purpose; and
  • at the document systems level - making discrete families of documents work smoothly and consistently together. 

Copyright - Statutory Licences

A wide range of copyright assets are involved in web and mobile app development. They mostly fall into four categories:

  • original source material - copyright in original source materials prepared for the site by employees or independent contractor who assign their copyright; the materials include for example text, photos, graphics, video, animations, musical compositions, sound recordings and software code;
  • licensed source material - copyright in any source materials which must be licensed because it is owned or controlled by third parties (includes any Creative Commons material); and
  • original software code - copyright in original software code written for the site or app; and
  • licensed original software code - copyright in software code which must be licensed because it is owned or controlled by third parties (includes open source material).

As regards the above second bullet point there may be a need to obtain licenses from copyright collecting societies. Statutory licences, permissions and rights clearances are available from copyright collecting societies or copyright collection agencies. They represent their members (split typically along industry, media or guild lines) by administering licences, collecting fees and distributing them to their members. In Australia, a voluntary code of conduct regulates their conduct regarding such matters as licence fees, expenses, governance, accountability, complaints and disputes. In Australia the copyright collecting societies comprise:

Review Points 

  • A good foundational document comprises a contract that incorporates in whole or by reference documentation covering business, financial, management and technical needs.
  • Few contracts need to be in writing to be legally binding, however many misunderstandings and disputes are avoided by recording contracts in writing.
  • Structured contracts are best formed by working with pre-settled standardised elements, such as pre-designed contract document layouts, standardised clause heading wording and a chronological or other logical order of clauses.

Courseware © Annexium 2013