Through experience of IT-contracts I try to be aware of the following things:
- Operational requirements – the definition of task is clear and preferably even third party verifiable, which makes sure you are on the same page on what will be delivered.
- Clearly stated license for code (usually delivered under permissive open source on payment). This protects both you and your client.
- Quality assurance, – make sure that the contract explicitly states the quality of the delivered product in a measurable way, – for example be performance-wise, code quality, documentation etc.
- Structure of agile development process, communication and involvement on both sides. Are we working in sprints, how do we communicate backlog etc., transparency of development.
- Document collaborators and clients responsibility, – what happens with your part and payment, if your access to are delayed, or other component or the project halts.
- Accept/done-criteria, and payment. When is your role fulfilled.
Of course this is an incomplete list, but the points mentioned above have been useful to me when making contracts.