[IANAL]
I come from a field, AEC, which in the US uses a lot of standard contracts. The AIA contracts, though not the only option, are very common and have been developed over the course of 100 years.
The architecture series start with B. These are, in my opinion, a good model for a software consulting project because:
+ Neither party really knows the full scope of the work when the contract is let. As my mentor Ronn Ginn told me, two people sit down and sign onto something about which neither has much of a clue. This of course emphasizes that an agreement is really a matter of trust not which court to go to.
+ Client objectives change during the process. The contract reflects it.
+ Intellectual property rights are clear. The architect retains the copyright. The client is granted license to use it for the purpose of the project. The license is predicated on payment.
+ Terminating the contract for convenience is a distinct possibility. The contract acknowledges that.
+ One person is the technical expert. The other party hires them for their judgement. The contract acknowledges that.
+ Both parties are likely to contract with others during the course of the project [architect with consultants, owner with builders]. The contract acknowledges that and one of the reasons for using standard contracts is because they all fit together. But that's too much to hope for here. The idea of acknowledging the possibility of other contracts and taking them into account is what matters.
The short form agreement, AIA B105 currently, B155 previously, is a good place to start. Both use simple plain language and cover most projects.
Having written a lot of proposals and contracts over the years, I've learned that selecting clients matters more than what's in the contract. Red flags really are red flags.
Good luck.