I'm a freelance web developer and I'm planning on putting together a general purpose web development contract for future projects. I was hoping to get a feeling of what I should be covering in the contract. I'd love to make a easy to read, non-legalese contract that covers the basics (payment, ownership, expectations, work hours etc.) which would give a client an introduction to my terms and be tweaked on a per-project basis.<p>I understand that I/WANAL & YMMV etc. but it would be nice to see what people are using themselves.
[IANAL]<p>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.<p>The architecture series start with B. These are, in my opinion, a good model for a software consulting project because:<p>+ 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.<p>+ Client objectives change during the process. The contract reflects it.<p>+ 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.<p>+ Terminating the contract for convenience is a distinct possibility. The contract acknowledges that.<p>+ One person is the technical expert. The other party hires them for their judgement. The contract acknowledges that.<p>+ 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.<p>The short form agreement, AIA B105 currently, B155 previously, is a good place to start. Both use simple plain language and cover most projects.<p>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.<p>Good luck.
I work on small projects (from $5k to $50k) and have no formal contracts. My thinking is that:<p>- the client can afford more expensive lawyers than I can, so regardless of the truth they would be able to wipe me out<p>- if the client has to read the detail of the contract, it's probably too late to save the relationship anyway<p>- maintaining the relationship is everything, being honest and open and striving to maintain a service that is genuinely useful to the client, even if you're not always perfect.<p>I do have a contract with one client but any questions about it have been about the 'spirit' of it, not the detail.<p>Pricing is everything: if you're too cheap, you'll struggle to deliver and will not meet expectations. Too much, and you'll lose out to your competitors.
These days, I usually have a recorded sit-down (in person or over the phone) and discuss very specific details with the client and inform them that this recorded conversation will be the basis for the beginning of an agreement.<p>We then share the recordings with them, along with a written summary of the agreement.<p>Fortunately we've never had to go to court, but I'm told by my lawyers that this will hold up just fine. It also seems to breed a more organic agreement than a sterile, boilerplate contract.
Here's what I used last time:<p><a href="https://gist.github.com/malarkey/4031110" rel="nofollow">https://gist.github.com/malarkey/4031110</a><p>I like the plain language of it. For me, contracts are a necessity. The way I see it is that people who want to not pay, won't pay. You'd need an army of lawyers to craft a bulletproof general purpose contract. Instead, I go by a mutual understanding sealed by a simple contract.<p>From what I understand, the best tool/weapon you have is a clause that says that copyright assignment from you to them happens upon receipt of full payment. That way you hold their work until you get paid. YMMV and IANAL.
Whenever possible, I try to strike Agile Contracts where the client is given control ONE of three levers: The Scope lever (how much will be done). The Time lever (how much time will be spent). The Money lever (how much will the client spend). If you try to give your client more than one of these levers, you're fooling yourselves, because it isn't really possible. Some aspect of the project will suffer in a way that violates the basis of a good business relationship and / or a good outcome.<p>More information on Agile Contracts:<p><a href="http://www.agilecontracts.org/" rel="nofollow">http://www.agilecontracts.org/</a>
Have you tried Docracy? There are a few good examples at:<p><a href="https://www.docracy.com/application/dochome" rel="nofollow">https://www.docracy.com/application/dochome</a>
The ones I use are on the sidebar of my blog; which I posted in conjunction with an article I wrote ( Deconstructing the Consulting Contract ) for a print publication called Fusion Authority Quarterly Update (FAQU):<p><a href="http://www.jeffryhouser.com/download.cfm/dir/software/file/contracts%2Ezip" rel="nofollow">http://www.jeffryhouser.com/download.cfm/dir/software/file/c...</a> . I do not know if the article is still available anywhere; it is from 2005. [Maybe I should update said documents; but primarily very little has changed]<p>Bigger clients will have their own contracts [and sometimes very little negotiation room]. I've drive some clients crazy w/ negotiations and about what rights I refuse to sign away.<p>Update: Here is the original article I wrote <a href="http://www.jeffryhouser.com/enclosures/DeconstructingConsultingContract.pdf" rel="nofollow">http://www.jeffryhouser.com/enclosures/DeconstructingConsult...</a> [I guess it was 2007; not 2005]
This one is really cool <a href="http://tri.be/update-the-shane-peter-inc-contract/" rel="nofollow">http://tri.be/update-the-shane-peter-inc-contract/</a>
I use a modified version of Ross Kimbarovsky's Contract from: <a href="http://www.crowdspring.com/contracts-for-software-and-website-developers/" rel="nofollow">http://www.crowdspring.com/contracts-for-software-and-websit...</a><p>Caveat: I've only used it with one client, with whom I have a prior working relationship.
Myself and a number of others have used this generic development and design contract: <a href="https://github.com/danielbeardsley/service_contracts" rel="nofollow">https://github.com/danielbeardsley/service_contracts</a><p>I negotiate the terms, make local commits, and include the commit hash on the print-out.
[IANAL]<p>Been using this one for a few years, wrote it with some mates, never had any issues. Attached some design images as well as the text.<p><a href="http://teamgoblin.com/contract.html" rel="nofollow">http://teamgoblin.com/contract.html</a>
<a href="https://github.com/cweagans/Contract" rel="nofollow">https://github.com/cweagans/Contract</a><p>Fork and modify. I accept PRs too ;)
You should try Shake!<p><a href="http://www.shakelaw.com/legal-info/freelancehire-agreements/" rel="nofollow">http://www.shakelaw.com/legal-info/freelancehire-agreements/</a>